For auditors, insurers and regulators
Regent is not a regulated entity, and it does not make anyone compliant. The obligations below sit with the bank, the payment service provider or the company that runs the agent. Regent supplies evidence about the money an agent tried to move: who authorised it, under which limits, what a person decided, and what the rail says actually settled.
This page lists the questions reviewers ask us, what answers each one, and where the answer stops.
The mapping further down is structural: a record Regent keeps lines up with what a provision asks for. It is not a legal opinion and not a claim of equivalence. Whether a provision applies depends on your role, your system and your jurisdiction.
Questions reviewers ask
Who authorised this payment, and under which limits?
Every receipt names the mandate version and a salted hash of its terms (mandate_version,
mandate_hash), the policy version and hash, and how a person approved (approval_method,
approval_digest). The owner gives a reviewer the terms and the salt; the reviewer recomputes the
hash. See Receipt and Mandate.
Where it stops: it proves which terms were in force and that a passkey approved them, not that the terms were sensible.
What actually left the account?
settlement_source in the receipt says who attested the outcome: provider (the rail’s own signed
event, such as Stripe or Agentcard), custodian (the custodian’s ledger and the chain),
counterparty (a signed confirmation from the party that received the money) or agent (the
caller’s own report). See Settlement confirmation.
Where it stops: agent means nobody else vouched for the figure. Read the field.
The counterparty itself is in the receipt as a salted commitment (payee_hash, payee-v1), with the clear
name beside it unless the organization hides payees in its receipts. Either way the owner can hand you the
reveal for one decision ({payee, salt}), and regent-verify --payee reveal.json confirms that this receipt,
and no other, paid that party, without the name ever being readable from the receipt alone.
Could the agent have paid without Regent?
Not on a rail whose key sits in Regent’s vault: the agent never holds that key, so every payment there passes the decision first. See Gateway.
Where it stops: money the agent moves with credentials it holds elsewhere is outside Regent’s view.
Can a person stop it before the money moves?
Above the owner’s allowance a payment waits for a person, who approves or rejects it with a passkey. Revoking the agent refuses every later call at once. See Oversight and the kill switch.
How do I know nothing was edited or deleted?
Every decision, refusals included, is an audit event kept with its exact bytes, a Merkle proof to
its batch root, a signed checkpoint chained to the previous one, an OpenTimestamps proof and an
RFC 3161 time-stamp token from a public Time Stamping Authority over the epoch root. An
evidence bundle carries all of it in one file, from the console or
GET /v1/organizations/ORG/audit/events/EVENT_ID/bundle, and regent-verify bundle checks it.
See Audit trail.
Where it stops: the Solana anchor runs on devnet today (Status); the RFC 3161 token (DigiCert’s clock and signature, checked offline against DigiCert’s root) and the OpenTimestamps proof on Bitcoin are the time anchors that do not depend on us. The record shows nothing was changed; it covers only what passed through Regent.
What if Regent disappears?
Receipts and evidence bundles are JSON the organization exports. The verifiers are open source (Apache-2.0) on PyPI and npm and run offline against keys you saved; no check calls Regent. See Receipt: verify one.
What does Regent keep about people, and where?
Verdicts, not documents: identity documents, faces, card and bank numbers stay with the verification provider or the rail. Hosting, subprocessors and retention periods are on Security.
Where it stops: a receipt names the payee in clear today (a merchant name or a customer id).
Show me everything for a period
Per decision, the evidence bundle above. Per agent, its journal through the Audit API. A single file covering a whole period is not a product export today.
How the records line up, for money
PSD2 (Directive (EU) 2015/2366)
| Provision | What it asks | What Regent records | Where it stops |
|---|---|---|---|
| Art. 64(1)–(2) | a payment is authorised “only if the payer has given consent”, in “the form agreed between the payer and the payment service provider” | a mandate signed with a passkey: standing consent to a series of payments within limits; a passkey approval for one payment above them; both named in the receipt | consent is given to the PSP in the form the PSP agrees; Regent’s record is evidence the PSP can rely on, not consent on its behalf |
| Art. 97(2) | strong customer authentication with elements that “dynamically link the transaction to a specific amount and a specific payee” | the approval a passkey signs carries the amount, currency, action and resource of that one payment | strong customer authentication is the PSP’s to apply; the payee is bound through the action’s resource, not a separate payee field |
EU AI Act (Regulation (EU) 2024/1689)
These articles bind high-risk systems (Annex III). An agent that pays or buys is usually not one; credit scoring and life or health insurance pricing are.
| Provision | What it asks | What Regent records | Where it stops |
|---|---|---|---|
| Art. 12(1) | systems “technically allow for the automatic recording of events (logs) over the lifetime of the system” | every decision, allowed or refused, as a hashed, anchored audit event | covers what passes through Regent, not the agent’s other activity |
| Art. 14(4)(d)–(e) | people can “disregard, override or reverse the output” and “interrupt the system through a ‘stop’ button or a similar procedure” | escalation before money moves; rejection with a passkey; revocation of the agent | for actions routed through Regent |
| Art. 26(6) | deployers keep the logs “of at least six months” | receipts kept ten years in the organization’s audit trail, exportable | retention of the agent’s own logs is the deployer’s |
DORA (Regulation (EU) 2022/2554)
When a financial entity uses Regent, Regent is its ICT third-party service provider.
| Provision | What it asks | What Regent records | Where it stops |
|---|---|---|---|
| Art. 28(8) | exit strategies that let the entity remove the service and its data and “integrally transfer them to alternative providers or reincorporate them in-house” | evidence that verifies offline with open-source verifiers and saved keys; receipts and bundles export as JSON | the exit terms live in the contract; the software makes them workable |
| Art. 30(2)(b) | the “locations … where data is to be processed, including the storage location” | the hosting region and every subprocessor on Security; changes announced before they take effect | — |
| Art. 30(2)(d) | “access, recovery and return in an easily accessible format” of the entity’s data | receipts, bundles and audit events as JSON | — |
MAS SAFR (Safeguards for Agentic Finance at Runtime, July 2026)
Voluntary guidance from the Monetary Authority of Singapore, co-authored with Visa, Mastercard and Circle. Its four runtime components:
| SAFR component | What Regent runs |
|---|---|
| Agent Identity | an AgentID bound to a verified owner |
| Controls Repository | mandates and Cedar policy, versioned and hashed |
| Disposition Engine (Auto-Execute, Observe, Escalate, Deny) | the gate: allow, deny, escalate; the organization’s enforce or observe mode is recorded with every decision |
| Audit Log | append-only events, Merkle roots, signed checkpoints, anchoring |
GDPR (Regulation (EU) 2016/679)
| Provision | What it asks | What Regent records | Where it stops |
|---|---|---|---|
| Art. 5(1)(c) | data “limited to what is necessary” | public chains receive hashes only; documents, faces and card numbers are never stored; receipts can carry the payee as a salted commitment only, revealed per decision by the owner (payee-v1) | organizations that keep payees open (the default) name them in receipts and decision events; a hiding organization’s trail carries the commitment and a sealed copy only, and a bundle names the payee only when the owner asks for the reveal |
Not covered today
- Sanctions screening of payees is not built in. A policy can key on a screening result from a connected tool (Tool catalog).
- Third-party assurance: a SOC 2 audit and a penetration test are next (Status).
- Solana mainnet follows the audit of the programs; the anchor is on devnet today.
- National rules such as Kazakhstan’s AI law (No. 230-VIII, in force since 18 January 2026) are not mapped article by article yet.