Skip to main content
DoneThat

AI Adoption GuideBankingOpen

Thin-file credit limit calibration

ML scores applicants with limited credit history using alternative data, such as open banking flows, device signals, and behavior, to assign initial credit limits.

Banking processAcquireOnboardOpenFundTransactServiceReviewClose

By Don, DoneThat’s AI coach · updated

Empty bureau is missing data, not a decline

An empty or near-empty bureau file is a data state. It is not evidence that the applicant cannot repay, and it is not permission to invent the missing fields. Credit still owns the initial limit. The quality outcome is a documented starter limit from consented alternative data, bound by policy caps, with reason codes that name what was used and what was held out.

Thin-file applicants typically have no revolving tradelines, a very short file, or no bureau match. That pattern is common for young adults, recent arrivals, and people whose history sits under a different name or address. Route them onto a thin-file policy. Do not auto-decline on emptiness. Do not fill income from a job title.

Bureau files from providers such as Experian and Equifax remain the first lookup. A no-hit or thin-file flag is the trigger to collect consented cash-flow evidence, not a substitute for it. Open-banking connections through providers in the class of Plaid or TrueLayer are usable only after the applicant has consented, the link is attributable to that person, and the accounts in view are ones policy treats as income and commitment evidence.

A marketing score is not an underwrite. If the application also carries a propensity-to-open scoring result, keep that score in origination targeting. Do not let it raise the limit, waive a cap, or stand in for affordability.

Detect the thin-file cohort before you score

Define thin file in credit policy before any alternative-data model runs. Use bureau attributes you already store: tradeline count, age of oldest account, whether the file is scoreable, and no-hit versus thin hit. Write the threshold in policy, not only in a notebook. The same applicant must land in the same cohort from a branch journey, a digital funnel, or real-time pre-approval at point of intent.

Keep identity and fraud off the limit equation. Device, session, and velocity signals belong with identity and with first-party fraud detection at first deposit. They can stop an application. They must not become a numeric stand-in for a credit score. A clean-looking device ID is not ability to pay. A risky device is a reason to stop, not a reason to haircut a limit you had no grounds to grant.

Confirm consent and recency before you treat open-banking flows as underwriting inputs. Record which accounts were linked, the consent timestamp, the transaction window, and whether salary-like credits were labelled by the connectivity provider, by your own rules, or by the applicant. Missing, stale, or partial consent means you do not have an alternative-data underwrite. You have an incomplete file. Emptiness is still not a decline. Incomplete evidence is a refer or a decline only when policy requires cash-flow proof you do not have.

Consented cash flow and first-party behavior, then a cap

The thin-file underwrite is observed cash flow plus attributable first-party behavior, converted to a limit that cannot exceed policy.

Use regular incoming credits that look like earnings, their stability across the consented window, commitments visible as debits, and residual after those commitments. Do not convert a stated occupation into a salary. A job title is a claim. Mapping that title through a typical-pay table fabricates affordability.

Use first-party behavior only when it is this customer and this legal entity: funding a current or savings account you hold, a payroll switch onto your account, or on-time payments on a product already on the books. A household device, a shared IP, or a lookalike segment is not first-party credit evidence.

The model may recommend a starter limit. Credit policy books the number: floor, cap, step size, and product ceiling for unsecured thin-file. If the model exceeds the cap, the cap wins. If residual fails the affordability rule, that rule wins. If features are missing, refer or decline under incomplete evidence. Do not smooth a missing income field.

Illustrative path, not a measured result: a recent graduate applies for a revolving product. The bureau returns no scoreable tradelines. They consent to open banking. The linked current account shows regular credits from a named employer and a standing rent debit. Identity has cleared. Credit books an initial limit at the product's thin-file starter cap, not at the model's unconstrained suggestion, and not higher because a take-up score said they would accept a card. The decision record states which accounts were used, that income came from observed credits rather than from the job title "analyst," and that the cross-sell propensity at account opening score was stored for later offer design and was not an input to the limit.

Credit owns the booked limit

Product and growth teams can own the journey. They cannot own the number.

Write thin-file caps next to every other limit rule: a maximum for unsecured thin-file, a maximum as a share of observed residual, a maximum until the bureau file seasons, and the conditions for a later increase. The initial calibration is a starting bound. Once the account is live, continuous credit risk reassessment can raise, hold, or cut that bound using performance, new bureau data, and refreshed consent. Reassessment is a new decision with new evidence. It does not rewrite the original starter-limit reasons.

Keep credit features and non-credit features apart. Credit features are consented flows, first-party payment behavior, bureau attributes when present, affordability residual, and the policy cap. Non-credit features are propensity to open, propensity to respond, device reputation used as if it were a score, channel, campaign, and offer elasticity. If a feature cannot appear on a customer credit explanation as a credit reason, it does not belong in the limit model.

Overrides stay with named credit authority. A digital boost-limit test is not an exception process. Log who changed the limit, which cap was waived, and why. If you cannot name the waiver, you had leakage, not an exception.

Reason codes and the substitutions that fail review

Every booked thin-file limit needs reason codes a second credit officer can reconstruct: the cohort rule that fired; bureau result (no-hit, thin hit, unscored); consent and which accounts were in view; how income and commitments were derived; residual versus the affordability rule; the cap that bound the limit; the booked limit; and which scores were computed but not used for the underwrite.

Treat these three substitutions as defects.

Do not use device ID as a credit score. Device and network signals support identity and fraud. Folding a device-risk quantile into the limit attributes repayment capacity to hardware. When the device looks good, you grant credit you did not underwrite. When it looks bad, you may decline for a reason you cannot explain as credit. Keep device features in the fraud decision.

Do not invent income from a job title. Occupation and employer name can support identity consistency. They cannot be mapped through a salary table into monthly income for residual. If open banking does not show earnings-like credits, you do not have observed income. Refer, collect documented income under the existing verification standard, or decline for insufficient evidence. Do not impute.

Do not treat propensity to open as affordability. Likelihood of acceptance is a commercial fact, not residual income. Mixing that score into the limit, or using it to skip a cap, turns a marketing model into an underwrite. Later loss analysis then cannot separate thin-file credit risk from offering more credit to people who were simply easy to convert.

Success on this work is narrow. A documented initial limit, from consented alternative data, inside policy caps, with credit as owner, and with an empty bureau treated as a routing signal rather than as a no or as a license to guess. If those pieces are not on the decision record, you do not have thin-file limit calibration. You have a score in a slide.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first