Early Advance

Users split by float rank (completed-float count); the populations are disjoint, so exactly one path can apply to a user and there is no fallback between them. Both produce the same outcome — only how the user qualifies differs.

A rank >= 7 user excluded from the experiment, or one who fails a float-rank check, gets nothing — the outcome is recorded, not retried against the other path.

Both paths share one precondition, resolved by the rule runner (it needs float-service and payments-service calls the rules cannot make): the user’s most recent float is ACHSENT with no other outstanding float, its latest collection attempt submitted a debit (carries a payment confirmation ID), and that payment is still an ACHSENT debit. The gate also reports which collection run produced the debit and how many debits exist for the float.

Per-path collection requirements on top of the gate:

The floats.collections.day_before.returning_float_ach operations flag is not read by either path; the collection log is the record of what ran.

Each path is gated by a string-valued GrowthBook feature that assigns an arm (Feature Flags): early_advance_transactions_group for rank 0, early_advance_float_rank_group for rank >= 7. The transactions path additionally sits behind the underwriting.rules.early_advance_elligibility_checks kill switch.

The float-rank path’s payments-service lookup (for the attempt ratio) is fetched only for users over the rank bar and in an arm; a failed lookup drops the user from the experiment rather than recording a denial.

Paid-subscription run — the last 3 billed cycles must be COMPLETED back to back. Leading future-dated SCHEDULED cycles are skipped; counting stops at the first non-COMPLETED cycle, so a WAIVED or errored cycle breaks the run. [SCHEDULED, COMPLETED, WAIVED, COMPLETED, COMPLETED] is a run of 1, not 3.

Repayment-attempt ratio — debit attempts divided by the user’s 3 most recent COMPLETED floats; must be non-zero and at most 1.4 (one retry in the window passes, two do not; both constants live in pkg/rules/rule_good_standing.go). A completed float with no debit on record still counts in the denominator, so the ratio can be below 1 — a low value may be a clean run or a payment-data gap; repayment_attempts and floats_considered are persisted to distinguish them. A ratio of exactly zero denies (attempt_ratio_zero). The in-processing float is never in the window. This measure is distinct from RuleCollectionsErrors' error_ratio (failed Usio debits, whole history, includes subscriptions) — they are not interchangeable.

Rules stay pure functions of RuleExecutionData — the rule runner resolves the experiment arm and hands it over on the gate (EarlyAdvanceGate.Group), so the recorded arm always matches the arm that gated the data.

Each stored evaluation also reports early_advance_qualification on the summary-history responses (pkg/dynamo/evaluation_results.go, EarlyAdvancePath): the path that cleared the user, null when no path did. It reads early_advance_experiment.granted OR the top-level ID pair, defaulting to transactions for records that predate the qualification field. It records the past decision; the live check below is the authority on current eligibility.

The float-check and eligibility endpoints re-verify a stored grant along the same path that granted it (early_advance_qualification):

The day bucket is the number of business days (weekends and federal bank holidays skipped) between the float’s due date and now, 0 = the due date. Days 0–2 share the same checks: a floatme transaction whose amount equals float + fee, no return/reversal transaction, and no reversing floatme credit. A day with no entry denies. Descriptors are normalized (lowercased, non-alphanumeric stripped) and amounts compared in cents. A stale recorded decision self-corrects when the bucket advances — there is no cleanup job.

The result is surfaced as early_advance_eligible on the float-check response and float_stacking_eligible on the eligibility-check response (name retained for app compatibility), with early_advance_float_id/early_advance_payment_id included when eligible.

The rule runner builds the early_advance_eligible payload (email, collection-payment metric fields) and carries it on user_rule_run_completed; the result runner decides whether to send, from float_results.approved and early_advance_experiment.granted — carrying a payload is not permission to send, which is what keeps holdout users from being nudged. Sent via Iterable with user_id, float_id, day, and end_date (the business day the bucket rolls over). Failures are logged and never fail the result run.

underwriting.early_advance.decision (Datadog counter), emitted for both arms — filter on group before reading approval rates. Tags:

payments.ach.early_advance_float tracks event:user_notified and event:float_created (tagged payment_amount, payment_processor, business_days, process — not qualification). Every float-rank decision also logs float rank early advance <arm> - <verdict> with all check inputs.

Source: pkg/float_evaluation/early_advance.go, pkg/datadog/metrics.go