Automated document analysis for credit

The data that does not arrive over an API

In consumer credit almost everything resolves with structured sources: bureau, internal behaviour, alternative data. The moment the operation involves a company or a collateral, the information that decides stops living in an API and starts living in a document that someone has to read, interpret and key in by hand.

That manual step is where the analyst’s time goes, where typing errors creep in, and where traceability breaks: the decision is on the record, but where each figure came from is not.

• The analyst stops transcribing and starts reviewing exceptions.
• The same criteria apply to every file, without varying between people or between days.
• It is on the record which document came in and what was read from it, alongside the rest of the decision.

Which documents it reads, by operation

The agent recognises commercial documentation for individuals and for companies. What changes from one product to the next is not the engine: it is which document settles the decision.

• Factoring: invoices and supporting documents, to assess both the seller and the debtor on the invoice.
• Corporate lending: balance sheets and financial statements, to read solvency, leverage and capacity to pay.
• Mortgages: proof of income and the documentation backing the collateral.
• Consumer: proof of income for individuals, when the bureau is not enough to resolve.

Factoring: the decision is not only about who asks

Factoring carries two risks at once: the seller presenting the invoice and the debtor who has to pay it. The documentation of the operation defines both, and today it is reviewed by hand, operation by operation — which caps how many can be processed in a day.

The engine reads the invoice and its supporting documents, extracts the data and applies the policy to both sides inside the same decision, combining them with whatever the bureaus return.

• Reads the invoice and the documents backing the operation.
• Policy on the seller and on the debtor of the invoice, in a single flow.
• What the document says is cross-checked with bureaus, alternative data and your own models.
• Every factoring operation is on the record with its documentation and the policy version applied.

From document to rule, with no manual step

Extracted values enter the flow like any other variable: compared against thresholds, fed into a scorecard, or cross-checked with what a bureau returned. The policy does not care whether the figure arrived over an API or came out of a balance sheet.

And like everything else, it is versioned: you can reconstruct which policy was live, which document was processed and what was extracted from it.

• Values from the document are available to the rules inside the same decision.
• They combine with bureaus, alternative data and your own models in a single flow.
• The case that needs human judgement is routed to review with the evidence already gathered.

What to evaluate before automating document reading

Before comparing vendors it is worth answering a few questions — the ones that decide whether this holds up two years in.

• What happens when the document comes in poorly scanned or incomplete?
• Can I reconstruct what was extracted from a document six months ago?
• Does the reading live inside the engine, or is it a separate vendor to integrate and audit on its own?
• Can I change what I do with an extracted value without depending on development?