The policy decides clear cases, and underwriters get the rest

Underwriters work from a checklist, or rules sit in the origination system. Decisimo runs the policy for clear applications. The lender’s system sends referrals to an underwriter as cases with the work already done.

Start free See the application path

The path an application takes to an underwriter

One decision flow answers clear applications in the call it receives. Referred applications reach an underwriter as a case.

  1. Application

    The lender’s system sends one JSON document to the decision flow’s endpoint.

  2. Knock-out

    A knock-out sets the decision and sends the application to the end, so no data source is called.

  3. Data sources

    Bureau and fraud data sources run in parallel; a failed source leaves its values absent.

  4. Affordability

    Functions compute debt to income and the instalment from formulas built in an editor.

  5. Scoring

    A scorecard or an uploaded model scores the application.

  6. Policy decision

    A decision table writes approve, refer or decline and the reason.

  7. Referral

    The lender’s system sends referrals to a case type endpoint; the underwriter works them and the decision returns to the callback URL.

The underwriting policy as a table the credit team edits

The credit policy is written as decision logic the credit team can edit. Approve, refer and decline are values the policy writes, and each decision table row can write a reason. Every threshold, band and reason in the illustration belongs to a demo case. The response carries the decision and the reason.

Decision table shows knock-out, debt-to-income, score and factors rows producing approve, refer or decline with reasons
The drawing shows an underwriting decision table with knock-outs, debt to income, score and compensating factors. The credit team can change the policy rows and the reasons they produce.

A referral reaches the underwriter as a prepared case

The lender’s system sends the referred application to a case type’s endpoint, and a case opens. The case turns the payslip into text, a model reads income from that text, and a decision task runs the affordability check before a person sees it. The task goes to the Underwriter role’s inbox, where the underwriter records what the form asks. The decision is posted back to the lender’s callback URL.

Referral flow from lender application A-2291 through a loan case to the underwriter’s inbox and callback decision
The drawing shows a referral moving from the decision flow to a case with document reading, a model, an affordability decision and an underwriter. The credit team sees the work completed before the person reviews the case.

Change a threshold and see which decisions move

The credit team edits the consumer credit policy in the portal, and every save creates a revision. The same applications run through the current and proposed policy, with decisions that would change listed. A change goes live as a release, with sign-off by roles where the endpoint asks for it, on the same URL.

An underwriting decision engine next to origination

Decisimo runs the underwriting policy and the review. Collecting documents from applicants, e-signature, identity verification, disbursement and messages to the applicant stay in the lender’s own systems. The origination system calls the decision flow and receives the answer.

Questions we get asked

What is automated underwriting?

Automated underwriting is an underwriting policy written as decision logic that decides an application without a person. It decides clear applications and refers the rest to an underwriter. Decisimo runs the policy and returns its decision for the lender's system to use.

Which applications should go to a person, and who decides that?

The policy decides approve, refer or decline using the rules the credit team defines. A knock-out can end the decision in the call. The lender's system sends a referral to a case endpoint for an underwriter.

What does an underwriter see when an application is referred?

The underwriter sees the briefing and case file, including completed data and document tasks. The case can contain payslip text, income read from it and an affordability result. The underwriter records the fields the form asks for.

What happens when a document arrives after the review?

When a document task reads a changed document, the task runs again. A review already finished returns as a new task, and the earlier review stays on the case.

Can it use bureau data and our own score or model?

Data sources can provide bureau data. A scorecard turns bins and points into a score, and a model trained in Python, R or Julia can be uploaded and called.

How do we move from a manual underwriting checklist to rules?

The credit team can turn a manual underwriting checklist into decision logic by editing rule sets, decision tables, scorecards and functions in the portal. Each save creates a revision, and the current and proposed policies can be compared before a release goes live.

Start with your underwriting policy

Start free to put your underwriting policy into a decision flow.

Start free