The risk team changes the consumer credit policy
A cut-off change becomes a ticket to engineering or a vendor. Decisimo lets the risk team edit the policy and run a proposed revision over applications before release.
The whole underwriting policy as one decision flow
The credit bureau and fraud data are two sources in one data source step, called at the same time, and the step waits as long as the slower source. The flow applies knock-outs before any score and calculates debt to income with the new instalment in a formula built without code. The credit policy table writes a decision and a plain-language reason. Every threshold, score and chart in the screenshots belongs to a demo case, run on demo applicants. See fraud decisioning for fraud rules over a confirmed-fraud list.
See what a policy change does before release
Two revisions of the credit policy run over the same applications, with results shown side by side across measures the team defines. In the demo, the comparison adds a route for applicants with two years in the same job; knock-outs and affordability stay the same. A changed policy goes live as a new release on the same endpoint, so engineering ships nothing.
Read a decline back to the row that decided it
The scorecard breaks down each predictor point by point and sums the result to a final score. The fired row in the credit policy shows its reason and revision. An applicant who scored well was declined on affordability, with the ratio on the record. Each live decision's input and output can be kept in the lender's own Postgres database.
Limits, offers and collections use the same parts
Limits, offers and collections are decision flows built from the same rule sets, decision tables, scorecards and functions, and the lender's systems call them when they need a decision. See collections decisioning for treatment and channel after a missed payment. A decision that waits on a person is worked as a case running the same rule sets. See case work for decisions that wait on a person or evidence.
What an automated credit decision asks of the lender
Assessing the creditworthiness of a person is an Annex III high-risk use under the EU AI Act; those obligations apply from 2 December 2027. GDPR Article 22 applies to an automated decline today, and each decision's input and output can be kept in the lender's own Postgres database. Read the governance overview for the obligations in full.
Questions we get asked
What is a consumer lending decision engine?
A consumer lending decision engine runs credit policy logic on supplied application data and returns a decision. Decisimo runs that logic as one decision flow made from rule sets, functions, scorecards and decision tables.
How does a cut-off change reach the systems that call the decision?
A changed policy becomes a new release on the same endpoint, so the lender's systems keep calling the same URL. The release runs after deployment, and engineering ships nothing.
What happens when a bureau is slow or down?
Bureau and fraud sources are called together, and the data source waits for the slowest. If a source fails, its values return absent with an error flag, and the rules determine what happens to the missing value.
Can a lender use its own scoring model?
A trained model can be uploaded and called in a decision flow, with the lender's cut-offs and rules around it. Python, R and Julia models can be used.
Does it handle mortgages and secured lending?
Mortgage eligibility and price can be handled as one policy. See mortgage underwriting for secured lending.
Can a new policy be tested on part of live traffic?
A decision flow can split live traffic between two branches of a policy. The split is part of the flow that the lender defines.
See the effect of a credit policy change
Start by putting your credit policy into a decision flow and testing a revision against applications.