Two worked examples you can run

Both 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. Both 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 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.