Underwriting agents: what they may propose, who signs, what is recorded

A model can read an application and propose a decision. Whether that decision may be made, on what terms, and who has to sign it is a question the rules answer, not the model. This page walks that line for a lending workflow, using the rules and the runnable example this site already publishes.

BEAP v1.0 · PublishedDated 2026-09-15. A published version is never edited; corrections appear in the next. The profile Decionis publishes and implements, not a standard approved by any body.

Which underwriting, and where

Credit underwriting: a lender deciding whether, and on what terms, to lend. Not insurance underwriting. The draft's areas are banking areas, and none of them is a policy of insurance. No market is named: the example amounts are in the currency the made-up fixtures use, and the rules are made up with them. The profile does not interpret regulation and does not claim to satisfy any of it.

What the agent may propose, and what only the rules may make true

Let models recommend. Let policy decide whether the credit decision may proceed, and who has to sign it.

In a lending workflow there are four moments where a proposal becomes something the bank has done. Each is a separate action with its own sign-offs, and an agent proposing one never gets to make it true on its own:

• Approving the loan: the credit decision itself.
• Creating the facility once the decision is made.
• Changing the rate or the term before the money goes out.
• Releasing the money to the customer's account.

Raising a limit on an existing facility is its own area with its own chain; the home page shows it beside the others.

Who signs

The card below is rendered from the same rules the runnable example is checked against, so the thresholds here cannot drift from the ones the code enforces.

What a sign-off cannot do

The lender example turns away a credit officer's sign-off pasted from one loan onto another, an amount raised after the sign-off, and an unverified customer with every sign-off in place; the examples page lists all of them. One case matters most for an underwriting agent: if the affordability assessment is missing, the decision waits for it. The rules name the missing input, and a sign-off does not fill the gap. When an assessment has been done and failed, a credit officer decides; that is a decision about the customer, and it is signed as one.

What is recorded

The draft publishes one worked example as five filled-in files. It is a disbursement of 250,000 run under the draft's own made-up rules, which ask two officers to sign at that amount; the lender example's rules ask one. The two are different made-up policies, and the files are the draft's, not the example's.

• A loan disbursement instruction, filled in
• A set of sign-offs from two approvers
• An authority to execute one disbursement
• The record of one disbursement attempt
• An auditor's extract

When the core system goes quiet after the instruction was sent, the record says so. "We do not know" is an answer, and never a reason to send it again.

What a run of the example proves, and what it does not

The lender example runs against made-up customers and a made-up core system and exits with an error if any attack gets through. That shows the boundary held. It shows nothing about whether the credit decision was right, fair, or acceptable to any regulator; those are your model's and your compliance team's questions, and no run of this example answers them.

What runs where

A bank adopts this one step at a time: first watching what the rules would have said, then binding the sign-offs, then enforcing. What adoption takes walks the three steps. What the Decionis platform itself runs today for financial infrastructure, and what it is building with design partners, is stated on its own page; this page does not restate it. Links checked 2026-09-13.

What to ask for about authorisation and accountability

An underwriting team deciding whether to let an agent act should be able to ask for four things and get a file, not a promise. Each one exists today, in the draft or in the runnable example.

• Authorisation. For any decision the agent proposed: which rules were applied, in whose name, and the single authority to execute that was issued for that exact decision and claimed once. The records one instruction leaves behind walk it from issued to spent.
• Accountability. Who signed, what they were shown when they signed, and proof that the same sign-off cannot be reused for another decision. The sign-off chain above is the rule; the lender example turns away the reuse.
• Evidence of the effect. What the core system actually did, kept apart from the permission to do it, including the attempt whose answer never came back.
• Ownership. Which of those the rules produce, which the component in front of the core system produces, and which the bank must produce itself. The documentation says who builds what, and what is still open.

None of those files says whether the credit decision was right. They say whether it was allowed, by whom, and what happened next.

What the records give a model-risk or fair-lending review

A credit underwriting team is asked the same questions by its model risk management function, by its fair-lending reviewers and, where it applies, by an EU AI Act review: what was the model allowed to do, under which version of the rules, on which inputs, who approved each decision, and what happened afterwards. The records answer the part about authority and effect, in files, and stop there. Links checked 2026-09-14.

• Model risk management. For every decision the agent proposed: which rules were in force, by version; which inputs the rules read; the verdict and its reasons; who signed; and what the core system did. That is the use-and-control half of a model inventory. The other half, whether the model is sound, stays with the bank's model risk function, and no record here stands in for it.
• Fair lending. The reasons a proposal was blocked or held, as the bank's own reason codes bound to that one decision, and the sign-off that settled it. The records do not produce an adverse-action notice and do not test outcomes for disparate impact; the reason codes are the bank's rules in the bank's words, not a finding about the applicant.
• EU AI Act record-keeping. A signed, time-stamped log of what the agent proposed, what was allowed, under whose oversight, and what then happened, kept apart from the model that proposed it. The records are not a conformity assessment and say nothing about how a use is classified; that is the bank's determination, with its advisers.

The profile does not interpret regulation and does not claim to satisfy any of it. Whether any of these applies to your bank, and in which market, is your compliance team's call.

Bring one underwriting workflow

If your bank runs a credit decision with an agent in the loop, or is deciding whether to, hold the draft against it or write to beap@decionis.com. Please bring made-up values. Real customer data, real policies, and credentials do not belong in a review.