What "agentic" should mean inside a Singapore bank

Singapore wrote down what safe looks like

On 3 July 2026 a white paper called Safeguards for Agentic Finance at Runtime was published, shortened to SAFR. It was developed with financial institutions and fintechs under the BuildFin.ai initiative.

It is version 1.0 of an industry framework. It is not a rule, not a licence condition, and not a certification anyone can hold.

That matters for how you read it. SAFR is a shared vocabulary, and a useful one, because until now every vendor defined the word for themselves and no two definitions matched.

The checkpoint is the whole idea

Between the action an agent proposes and the action actually running, there sits a governance checkpoint.

At that checkpoint the proposed action is verified against mandates, policies and risk boundaries the institution defined in advance. Then it is recorded.

The paper is specific about the outcomes. The checkpoint evaluates each proposed action against the relevant controls and decides whether it can be executed, must be escalated for a human decision, or must be rejected.

Read that again with a financial crime queue in mind. The agent does not decide what it is allowed to do. The bank decided that earlier, and the checkpoint enforces the decision every single time.

This is the difference between a system that made a judgement you cannot reconstruct and one that applied a rule you wrote.

Four questions the framework lets you ask

The last one is the question teams forget to ask. A system that logs its successes and stays quiet about the steps it did not perform is giving you a highlight reel.

Why this fits financial crime work specifically

Financial crime operations are full of actions that carry real consequence. Restricting an account. Reporting a customer. Telling someone their money is not coming back.

Those are not places to discover afterwards what a model decided. They are exactly the places a checkpoint belongs.

The work on either side of the consequence is different in kind. Pulling account history, matching transactions, retrieving customer due diligence documents, drafting a rationale - that is volume work, and it is where the analyst hours actually go.

Separating the two is the practical version of what SAFR describes. Prepare in volume. Decide under control.

It is also where examiners have already looked. The 2025 enforcement action against nine institutions cited insufficient monitoring of transactions flagged as suspicious, which is a preparation failure before it is a decision failure.

The published evidence for designing it this way

There is measured support for the checkpoint design beyond the governance argument.

Across roughly 10,000 runs covering 150 distinct outcome scenarios, work broken into defined steps reached 93% coverage and an 82% success rate. An open-ended approach on the best available model reached 79% and 71%.

Defined steps on a cheaper model still beat it, at 91% and 80%. The design was doing more work than the model was, which is a useful thing to know before a licensing conversation.

What SAFR does not do

• It does not certify anyone. There is no compliant badge available, so a vendor claiming one is telling you something useful about the vendor.
• It does not replace technology risk or outsourcing expectations. It sits alongside them, and alongside your own model risk policy.
• It does not tell you whether a system is any good at the work. Safety and usefulness are separate questions.

A serious vendor should be able to evidence both, and you should ask for both in the same meeting.

Where CaseLEA sits

CaseLEA prepares the case and then stops. It retrieves evidence from approved sources read-only, applies the bank's own checks, drafts the rationale and shows its working.

A person confirms the disposition, approves anything that leaves the bank, and signs the record.

That boundary is not a limitation we apologise for. It is the same boundary the framework describes, and it was in the product before the paper existed.

How to use this in a procurement document

The framework's practical value is that it gives a bank language a vendor cannot redefine mid-conversation.

Put the four questions in the requirements document rather than the meeting. Written answers are comparable across vendors and they survive the sales cycle, which verbal ones rarely do.

Then ask for evidence rather than description on the fourth. A vendor claiming full reconstruction should be able to show a real record from a real case, redacted, including a case where something was skipped.

A vendor who can only describe the capability in prose is describing a roadmap.

What version 1.0 signals about what comes next

The version number is worth reading literally. This is an industry framework in its first published form, developed with financial institutions and fintechs, and it will move.

That argues for building to the principle rather than to the document. A checkpoint that verifies proposed actions against a scope the bank defined, and records the result, will remain correct whatever the next version says.

It also argues against waiting. A bank that designs its approval model now will be able to evidence it against whatever arrives, while a bank waiting for certainty will be starting from nothing.