Industries · Financial services

When an agent moves money, prove it.

Payment agents, treasury bots, dispute assistants and KYC copilots all leave the same question behind them: who authorised this, under which rule, and what exactly happened? R-Series answers with a hybrid-signed receipt for every step, chained and checkable offline by anyone with the public key; external anchoring is in development.

Follow one payment Five use cases

SignatureEd25519 + ML-DSA-65

Agent payment receiptsIn development

Money movementDark until a human GO

01 The question after every incident

Who authorised this, and what exactly happened?

Today the answer is assembled from logs. Tomorrow it should be handed over as evidence.

Banks, brokers, insurers and payment firms already run software agents: reconciliation bots, payment assistants, research copilots, customer-service agents with account access, and models that recommend whether to approve a customer. When one of them does something unexpected, the investigation starts from logs spread across vendors, written in different formats and often editable by the very people being investigated.

R-Series changes the starting point. Every instruction, approval and decision becomes a receipt: a small signed record that says what was intended, which policy applied, who approved it, what the downstream system actually did, and which receipt came before it. Receipts link into a chain, the chain rolls up into a Merkle root, and the root is designed to be anchored outside the institution (in development).

An auditor, a regulator's examiner or a counterparty can then verify the whole sequence offline, without access to your systems, and can tell if a single record was inserted, removed or edited later.

Because financial records are kept for many years, R-Series v2 receipts are designed to carry two signatures: Ed25519, which everyone can check today, and ML-DSA-65, the post-quantum standard, which keeps the record checkable after classical signatures weaken. Both must verify. The hybrid engine is in development.

Not logs you have to trust. Evidence you can check.

02 One payment, end to end

Arrive, verify, approve, chain.

Scroll through the four moments that turn an agent's payment instruction into evidence a third party can replay.

Payment receipt stream01 / 04

01 · ARRIVE

Transactions arrive. None of them is checked yet.

Card payments, cross-border transfers and treasury sweeps flow between New York, London, Frankfurt, Dubai, Mumbai, Singapore and Tokyo. Each is initiated by a different agent, under different keys and policies. Without a receipt, each one is just a pending line in somebody's log.

Intent declared by the agent ("pay supplier invoice 4471")
Nothing yet that a third party could check

02 · VERIFY

Every transaction passes the gate and is checked.

Each instruction is put into one canonical form, hashed, and signed twice: Ed25519 and ML-DSA-65. It leaves the gate as a receipt that the receiving side can verify on its own. If either signature fails, the receipt fails. There is no "mostly valid".

Canonical encoding (dCBOR), so two verifiers agree byte for byte
Key id and key epoch inside the signed body

03 · APPROVE

A high-value payment waits for two of two.

Above the policy threshold the payment is held at the gate. Two named approvers must sign before it is released, and the approval is itself a signed receipt that records which policy applied at that moment. Four-eyes stops being a screenshot in a ticket.

Approver 1 and approver 2 each sign; order and time are recorded
A missing or late approval is visible, not silent

04 · CHAIN + REPLAY

Receipts chain, roll into a root, and are designed to anchor outside the bank.

Each checked receipt links to the one before it. Batches roll up into a Merkle root that is designed to be anchored externally, so nobody, including the bank or DCS, can rewrite history quietly. An auditor takes the chain and the root and replays it with an offline verifier.

Inclusion proof for any single payment
Insertions, deletions and edits show up as mismatches

03 Inside a payment receipt

The why, the who, the rule and the result.

A receipt is small, structured and signed. These are the parts that matter to a bank, and what each one lets you prove.

Part	What it holds	What it lets you prove	State
Intent	The task the agent declared, e.g. "refund duplicate charge"	The agent acted inside the job it was given; drift is visible	In development
Policy + approval	The rule in force, the limit, and each approver's signature	Four-eyes happened, before the money moved, under that version of the rule	In development
Request digest	A fingerprint of the exact instruction sent	What was sent is what was approved; no field changed in between	In development
Provider effect	The downstream reference, e.g. a refund or payment id	The instruction had a real effect, and which one	In development
Chain parent	The previous receipt in the same workflow	Multi-step agent work can be rebuilt end to end, in order	In development
Hybrid signature	Ed25519 + ML-DSA-65 over one canonical pre-image	Integrity and origin today, and after classical signatures weaken	In development
Log inclusion + anchor	Merkle inclusion proof and an external anchor	The record existed at that point and was not inserted later	Planned

Honest gap. A dedicated anchor-time field is not in the receipt yet. Until the anchor proof lands, bundles run unanchored and are labelled that way.

04 Use cases

Where receipts pay for themselves.

Five places in a financial institution where an agent's action is later questioned, and what the receipt chain shows when it is.

TREASURY AGENTS

Cash sweeps and liquidity moves

An agent moves surplus cash between accounts every night, inside limits set by treasury. When a sweep looks wrong, the question is whether the agent broke the limit or the limit was wrong.

Declared intent and the limit in force at that minute
Approval receipt for any move above threshold
Chain of every sweep in the run, in order

"Sweep 2.4M to the operating account: within limit L-7, approved by 2 of 2."

CARD DISPUTES

Chargebacks settled with evidence

A customer says they never asked for the refund, or the duplicate charge. Today the dispute team reconstructs it from screenshots. With receipts, the exact sequence can be shown.

Customer request, agent intent, policy limit
Approving manager, refund reference, reconciliation
Shareable with the scheme or the customer as a bundle

"Refund duplicate charge: request digest matches; refund id reconciled to the original charge."

TRADE FINANCE

Documents checked by agents

Agents read letters of credit, bills of lading and invoices and flag discrepancies. Two banks and a buyer may all need to see the same check, without trusting one bank's log.

Digest of each document as it was read
The discrepancy found, and who overrode it
Receipts countersigned by both sides once federation opens

"Invoice amount differs from L/C by 0.4%: flagged, overridden by the trade desk with reason code."

KYC DECISIONS

Onboarding and screening

A model recommends approve, refer or decline for a new customer. Supervisors ask why a customer was declined, or why a screening hit was cleared, sometimes years later.

Which checks ran, on which version of the model and the rules
Who cleared a hit, and when
Personal fields encrypted so they can be erased without breaking the chain

"Sanctions hit cleared: rule set v14, analyst sign-off, evidence digest attached."

MODEL-RISK EVIDENCE

What the model did in production

Model-risk teams validate a model once and then need evidence that the validated version is the one running, with the agreed limits, every day after.

Model and prompt version bound into each decision receipt
Shadow-mode runs receipted before a new version goes live
Override and fallback events recorded, not inferred

"Credit model v3.2 ran in shadow for 30 days; 0 limit breaches; promoted by the model owner."

AGENT PAYMENTS

Payments initiated by agents

The newest case: an agent that pays suppliers, tops up wallets or settles invoices on behalf of a business. The receipt is the proof of what it was allowed to do and what it did.

Agent payment receipts: in development
Money movement stays dark until a human GO in every deployment
Settlement itself is not built and is not a switch to flip

"Pay invoice 4471: intent matched, policy P-2 applied, held for 2 of 2, released."

05 Dual control, signed

Four-eyes that a third party can check.

Instruction→Held ≥ threshold→Approver 1 signs→Approver 2 signs→Approval receipt→Released

Every bank already has dual control. What it rarely has is proof of dual control that survives a dispute: the approval lives in a workflow tool, the payment in a core system, and the link between them is an assumption.

In R-Series the approval is its own receipt. It names the policy and its version, carries each approver's signature, and is chained to the payment it released. A payment receipt above the threshold without a matching approval receipt is designed to fail verification. A rule changed in a hurry is a governance receipt too.

Two-of-two here means two separate approval signatures, each a receipt of its own. Splitting a single signing key across several holders (n-of-m) is not part of the current gates. Aligning approvals with the governance pattern is in development.

06 Where it stands

In development, and labelled that way.

Hybrid receipts, approvals as receipts, chains and per-subject encryption are in development. Agent money movement stays off until a human GO in every deployment, and the settlement path itself is not built.

In development

07 Boundaries

Evidence support. Never a compliance stamp.

R-Series produces evidence that maps to control requirements. It never declares an institution "compliant" on its own. Our crosswalks say "evidence support" or "partial alignment" where that is the truth, and examiners decide the rest.

Area	What the receipts can support	How we label it
ICT risk and incident records (e.g. DORA)	A tamper-evident timeline of what each agent did during an incident	Evidence support
Cryptographic inventory (e.g. PCI DSS)	Which keys and algorithms signed which records, by key epoch	Evidence support
Supervisory IT controls (e.g. RBI / SEBI)	Access, approval and change records produced as signed evidence, not exports	Partial alignment
Model-risk management	Version, limits, shadow runs and overrides per decision	Evidence support
Privacy and erasure (GDPR / DPDP)	Crypto-shredding: destroy a subject's key, receipts stay valid but no longer reveal the shredded data	Partial alignment · built-dark
Security frameworks (SOC 2, ISO 27001, ISO 42001)	Signed evidence of machine actions and credential events	Evidence support

Why banks, and why now. The roadmap's buyer order puts finance first for AI-agent evidence. Banks already have cryptographic inventory duties, but no duty yet to prove a migration, and examiners still accept documents. Receipts are how a bank gets ahead of the question before it becomes a requirement.

08 Why post-quantum, for a bank

Records outlive the cryptography that signed them.

A loan file, a trade confirmation or a dispute record may need to be checked fifteen years from now.

Retention periods in finance run to a decade or more. A record signed only with today's classical signatures may become forgeable within its own retention period, and then it stops being evidence. That is why R-Series receipts are designed hybrid from the first day: the post-quantum ML-DSA-65 signature sits next to Ed25519 and both must verify.

For the longest-lived records, R+15 adds an archive profile using a hash-based signature and scheduled renewal: old evidence is re-anchored under post-quantum primitives before its original protection weakens. Evidence renewal is in development; no retention commitment is offered yet.

R+15 long-horizon evidence and key lifecycle evidence (R+14), which shows when each key was created, rotated and retired, are in development.

09 How a bank starts

Observe first. Move money last.

The path is designed so that nothing touches a live payment until people at the bank say so.

Shadow mode

Receipts are minted alongside an existing agent workflow, observe-only. The shadow run is itself receipted, so the bank can see exactly what would have been recorded.

Offline verification

Internal audit gets the public verifier and the public keys, and replays the chain on its own machine, with DCS switched off.

Dual control on

Approval receipts are enforced above a threshold the bank chooses. A payment above it without an approval receipt is designed to fail verification.

Human GO

Only then, and only by an explicit decision of named people at the bank, is any money movement switched on. Until then it stays dark.

10 Questions

From risk, compliance and audit teams.

Does this make us compliant with a regulation?

No. No receipt makes anyone compliant on its own. R-Series provides evidence that supports controls, and the crosswalks label that support as "evidence support" or "partial alignment". Your examiners and your own control owners make the judgement.

Is agent money movement live?

No. Agent payment receipts are built and tested internally. Money movement stays dark until a human GO in every deployment, and the settlement path itself is not built, so it is not a flag that can be flipped by accident.

Can a counterparty or auditor verify our receipts without our systems?

Yes, that is the point. With the public keys and the chain they can verify offline. Countersigning by a counterparty's own node (federation) is in development and needs real partners before it opens externally.

Why two signatures on every receipt?

Ed25519 is fast and universally supported today. ML-DSA-65 is the standardised post-quantum signature. Signing with both means the record stays checkable even after classical signatures weaken, and a verifier rejects the receipt if either one fails.

What happens to customer personal data inside receipts?

Receipts carry digests, not documents. Where personal fields must be kept, they are encrypted per subject, so destroying that subject's key makes them unreadable while the chain still verifies. That sovereign-memory layer is in development.

Can DCS or the bank quietly rewrite the history?

Not without it showing. Each receipt links to the previous one, batches roll into a Merkle root, and the root is designed to be anchored outside the institution. An insertion, removal or edit breaks the chain or the root, and the verifier reports the mismatch.

Can we prove something about the records without sharing them?

That is the zero-knowledge layer. It is parked as research today: post-quantum zero-knowledge proofs are not mature enough to promise, so we do not.

What does a first engagement look like?

Shadow mode on one agent workflow, an offline verifier for internal audit, and a review of what the receipts would have shown. Nothing touches live payments.

11 The ledger room

Every decision sealed. Every seal checkable.

Receipts are kept like a vault keeps its drawers: each one sealed, each one numbered, each one openable by an auditor years later with nothing but a public key.

Book a briefing See verification

In development — talk to us about a design partnership.

Want the details for your sector? Book a briefing — we share the full design and a live demo in a private session.