DORA — Regulation (EU) 2022/2554
“Approved” is doing a lot of work in your access control policy.
DORA asks financial entities to limit access to legitimate and approved functions, to implement strong authentication with protected cryptographic keys, and to control ICT change management. In most estates “approved” means a role was granted months ago by someone who no longer remembers the request.
Entitlement is not approval
A role grant is a statement about a person's job. An approval is a statement about one action. Treating the first as evidence of the second is the ordinary practice, and it is also why the answer to “who approved this specific transfer?” is usually a reconstruction rather than a record.
Binding the signature to the parameters closes that gap. The approval covers this counterparty and this amount; it cannot be replayed against a different one, because verification re-derives the bytes from what is about to execute.
const action = {
target: PAYMENTS_TARGET, // this service — so the approval can't be replayed against another
actionType: "wire_transfer",
params: { beneficiaryIban, amountCents: 2500000, currency: "EUR" }
};
const approval = await intyga.requireApproval("Wire — 25,000.00 EUR", action);
if (approval.status !== "APPROVED") throw new Error("not approved");
// nonce and approvers come from YOUR side — a receipt cannot vouch for its own signer.
const anchor = parseTrustAnchorFile(readFileSync(process.env.INTYGA_APPROVERS_FILE!, "utf8"));
const TRUSTED_APPROVERS = trustAnchorApprovers(anchor); // quorum counts PEOPLE, not keys
const check = verifyApprovalReceipt(approval.receipt!, {
...action, nonce: approval.nonce!, approvers: TRUSTED_APPROVERS,
}, {
expectedOrigin: anchor.webauthn?.origin,
expectedRpId: anchor.webauthn?.rpId,
});
if (!check.ok) throw new Error("receipt mismatch: " + check.reason);
await submitPayment(beneficiaryIban, 2500000);What INTYGA evidences
Article 9 asks that access to ICT resources be limited to what is required for legitimate and approved functions. INTYGA reads "approved" per action: approval is granted against the exact parameters of one operation, not against a role for an indefinite window. A standing entitlement authorizes requesting; it never authorizes executing.
WebAuthn with user verification required. INTYGA never receives the private key that proves an approval; synced passkeys are supported unless the entity requires a hardware-bound authenticator. The entity still needs its own authentication and cryptographic-key policies.
This is the product. A change to a production system is gated on a human signature over its exact parameters, with four-eyes and hardware-key requirements configurable per action, and the resulting receipt is the evidence rather than a workflow status.
Each privileged change carries a named accountable human, kept distinct from the machine that requested it. requesterType: SERVICE with approverType: HUMAN is explicit in the record — and so is the case where policy auto-approved and no person was involved.
Every principal is a typed node — HUMAN, AI_AGENT or SERVICE — with a DID and explicit ownership edges, so the set of identities that can reach a privileged operation is enumerable rather than inferred.
An append-only, Merkle-anchored ledger with UPDATE and DELETE revoked on the ledger tables for the application's database role, plus per-entry inclusion proofs an investigator can verify offline.
Where the mapping stops
Prove it on one payment path.
Gate a single high-value transfer, hand the receipt to whoever will be asked about it, and let them verify it without calling us. That is a shorter conversation than a mapping document.
See the other framework mappings →