AI in credit decisioning

The short answer

A language model should not be the thing that approves or declines credit. That call belongs to your scoring model and your written policy, both of which are auditable and defensible.

What AI does well is everything around that decision: gathering and reading what the applicant submitted, explaining a requirement in plain language, and keeping a qualified applicant from abandoning a form they did not understand. We built into that surface at Banco BMG and credit conversion rose 30%.

Where the value actually is

Look at the drop between applications started and applications completed. In most lenders it is large, and most of it is not risk. It is friction: a document requirement nobody explained, a field that failed validation without saying why, a wait with no status.

Every qualified applicant lost in that gap is revenue that your risk policy already approved of. Recovering them changes the business without touching the risk position at all, which is why it is the right place to start.

The regulatory line

Draw it explicitly and write it down. The decision, the factors and the reason codes come from the deterministic system. The AI may explain that decision in the applicant's language, but it may not originate it, reword the reason into something different, or imply an outcome that has not been decided.

This distinction is what makes the project approvable. A system that assists comprehension is a different regulatory object from a system that makes the call, and conflating them is how a build dies in legal review.

What the AI actually does

It reads the documents the applicant uploaded and tells them immediately what is wrong, rather than after a two day manual review. It answers what income counts, why this document was rejected, what happens next and when.

For the analyst side, it assembles the case: pulls the file together, extracts the fields, flags the inconsistencies and shows its sources. The human still decides, faster and with better inputs.

The data and the permissions

Applicant records, document stores, policy documents and the decision system, all under access control that follows the requesting user. Nothing in this domain tolerates a system that retrieves broadly and filters afterwards.

Most of these systems are old and were not built for real time access, so budget the integration honestly. That is the recurring theme in legacy systems, and pretending it is small is how timelines slip.

Guardrails that are non negotiable

No invented policy, ever. No implied approval. No number the system of record did not produce. Full logging of what was retrieved and shown, because you will have to reconstruct an interaction months later for a regulator or a dispute.

And a refusal path that is genuinely used: the correct answer to an out of policy question is that a human will respond, not a plausible guess. That is deterministic control, per guardrails.

Bias is a live risk here

A system that explains requirements differently to different applicants, or is better at reading documents from one group than another, produces a disparate outcome even though it never made a decision.

Test for it deliberately, across segments, before launch and on a schedule after. This is one of the clearest cases for the reference set described in evals, with segment level breakdowns rather than a single aggregate score.

How you measure it

Completion rate among applicants who reach the step, time from application to decision, and rework rate on submitted documents. Then, critically, approval quality and default rate afterwards, to confirm you recovered qualified applicants and not marginal ones.

If the second set moves in the wrong direction, the first set was not a win. Measuring only the top of that pair is how a credit project reports success and creates a portfolio problem.

How to sequence it

Start on the pre decision surface, which is where value is high and regulatory exposure is low. Document explanation and status first, analyst assembly second, and nothing that touches the decision itself.

That order gets a system into production early enough to learn from real applicants, which is the difference between a pilot that crosses and one that does not, per why pilots fail. It is how we build production AI, end to end.