Three worked examples you can run

All three run end to end against made-up customers and a made-up core system. Each prints what it did, and stops with an error if any of the attacks against it got through. The claims on this site are things you can execute rather than things we assert. All three build on the Agent-Safe Pipeline, the open-source component that claims the grant, sends the instruction once, and records what came back; its source is public at github.com/decionis/agent-safe-pipeline.

A small business taken on, given an account, and lent to

One borrower, followed from the first proposal to the payout, through three banking areas with one set of rules each. An agent proposes every step; the rules answer every step. The customer record needs an onboarding maker and checker. The customer approval needs a compliance officer as well, because the risk assessment came back high; the maker and checker alone are not enough. The account opening needs four eyes, product and type included; the activation is blocked outright while the mandate is incomplete, and needs four eyes once it is not. The credit decision on a 180,000 facility needs the credit officer, and so does the payout, separately: the signature on the decision does not carry over to the money. A 60,000 working-capital facility inside the automated band is decided and paid with nobody signing. Every step lands once, is read back from the core system, and is confirmed only when what came back matches what was allowed.

Things it turns away:

• A customer approved with three sign-offs while screening is still pending: no sign-off gets past a block.
• The maker signing again as the checker.
• A checker's sign-off on one customer's record pasted onto another's.
• An account opened for a customer nobody has approved, with four eyes in place.
• An activation signed while the mandate is disputed.
• The account type changed after the checker signed.
• The credit amount raised after the credit officer signed.
• The payout redirected to another account after approval.
• An instruction of a kind the banking area does not list.
• A payment holiday in a banking area with no rules loaded: blocked, never waved through.
• A payout into an account nobody activated: the core system refuses it, the attempt is recorded as failed, and the spent authority does not come back.
• A core system that pays a different account: it is never reported as confirmed.
• The same grant used twice.
• A screening hit that arrives between the allow and the moment of sending.
• A lost response: the attempt stays open, someone checks what happened, and nothing is sent again on its own.
• A shadow-mode observation presented as if it were an allow.

A lender making three disbursements

Before any money moves, the demo governs the credit decision itself: a model proposes a 250,000 loan, the rules escalate it, a credit officer signs that exact decision, and only then is the facility committed to. What the underwriting agent may do on its own walks that step.

One small loan inside the limit the policy allows on its own. One at 250,000 that needs a credit officer. One at 750,000 that needs a credit officer and a risk officer, each signing the same instruction. All three pay out once, into the customer account that was approved.

Things it turns away:

• A request that arrives already marked as approved.
• An allow that the agent minted for itself.
• A credit officer's sign-off on loan A pasted onto loan B.
• The amount raised after the sign-off.
• The same approval used twice, and twenty-five requests racing for it at once.
• A core system that pays a different account: it is never reported as confirmed.
• A lost response: the attempt stays open, someone checks what happened, and nothing is sent again on its own.
• An unverified customer, at any amount, with every sign-off in place.

A corporate releasing a supplier payment run

A file of four payments arrives from the treasury system. It becomes a list of exact amounts and beneficiaries with a fingerprint over it. A maker, a checker, and two signatories sign that fingerprint. The run goes to the hub once, the account is debited once, and settlement comes back afterwards: two paid, one refused by the hub, one still pending, then finally three paid. The run is never reported as fully settled, because one payment was refused.

Things it turns away:

• One line's amount raised after everyone signed.
• A beneficiary account number swapped on one line.
• The file reordered, with every payment otherwise identical.
• A fifth payment added after the sign-offs.
• The signed fingerprint kept while the file on disk is edited.
• The maker signing again as the checker.
• One payment sent on its own using the approval for the whole run.
• A settlement report for a payment that was never in the run.
• A payment already settled being rewritten as refused.

Two Temenos integration patterns

Two packages show how a bank would wire this to Temenos Transact and to a Temenos payments hub. They are patterns, not ready-made clients: they carry no address, no credentials, and no sign-in, they have never been run against a Temenos system, and each one records exactly which public pages it was built from and the day those were read. Temenos marks belong to Temenos Headquarters SA. There is no affiliation and no endorsement.

A pilot rehearsal you can run

The component in front of the core system, built from the deployment kits' own files and driven the way a bank's workflow would drive it: in shadow first, where a release is recorded and never executed, then in enforce, where a maker and a checker sign the exact release and it is paid once and read back from the ledger. It runs against made-up stand-ins for a lending platform and for a core, and turns away the amount raised after the checker signed, the destination changed, a checker missing, a checker who is also the maker, a decision that was superseded, screening still pending, a response lost after the release, and a caller without the credential. Deploying it says what the kits contain.

Ninety days, evaluated: a Finance Control Evaluation

The evaluation a bank runs before anything changes, over ninety made-up days of one bank's finance operations: weekly supplier runs and monthly payroll, individual payments and returns, the bank's own funding movements and correcting entries, currency settlements, write-downs and concessions, limit changes, and rate and fee changes on the core. Each action is written in the profile's form and run against the synthetic rules in shadow at the moment it happened, with the facts the systems reported then and the sign-offs they recorded then. Nothing is executed and no authority is issued.

The run prints every verdict with the rule that decided it or the fact the rules could not see, adds it up into a Control Exposure Report by domain and by banking area, names the rules that held the most, and exits with an error if any action gets a verdict other than the one the history claims for it, or if any refusal turns out to have had no sign-off on it. It takes an extract of your own actions in the same form, so the first figures you see are yours. The figures on the home page are this run's.