Compliance mapping
Dynamic linking for AI agent payments
If you build in payments, you already know the design principle behind PSD2 Strong Customer Authentication (SCA) dynamic linking: an approval should be bound to the exact transaction details. Cosignet uses a similar payload-binding pattern for agent actions, generalized from "amount and payee" to "any agent action." This page explains the analogy, and states plainly where it ends.
Scope. Cosignet provides verifiable approval evidence only; it does not determine legal applicability, certify compliance, replace regulated controls, or substitute for legal, compliance, or audit advice.
Read this first: Cosignet is not an SCA provider, is not a certified PSD2 or SCA solution, and does not make your payment flows PSD2 compliant. What follows is an architectural analogy only, plus verifiable evidence. It is described honestly and is not a statement of regulatory conformity.
What dynamic linking is
Under PSD2, when a payer authorizes a payment, SCA requires that the authentication code be dynamically linked to the specific amount and the specific payee. Two properties follow, and they are the whole point:
- If the amount or the payee changes, the authentication code is invalidated.
- The code generated for one transaction cannot be reused to authorize a different one.
In other words, the approval is not a generic "yes." It is a "yes to exactly this," and it is cryptographically useless for anything else. That is what makes it strong.
Primary sources: PSD2 (Directive (EU) 2015/2366) and the SCA Regulatory Technical Standards (Commission Delegated Regulation (EU) 2018/389, Article 5, dynamic linking), on EUR-Lex. Confirm applicability to your payment flows with your own counsel.
The generalization
An AI agent action is a payment's more general cousin. A payment is "move amount to payee." An agent action is "run this operation with these parameters": deploy this commit, delete this bucket, wire this treasury movement, send this message. The risk shape is identical: something consequential is about to happen, and you want a human's authorization bound to the exact thing, not a vague thumbs-up that an attacker or a confused agent could repoint.
Cosignet does dynamic linking for the general case. The approver's passkey signs over:
challenge = nonce ‖ SHA-256(payload)The payload is the full, exact description of the action. Because the passkey
signature covers the SHA-256 of that payload, the same two SCA properties hold:
- Change any field of the action after approval, and the signed decision no longer matches. The signature is bound to the exact payload.
- An approval for one action cannot be replayed to authorize a different action. The challenge is one-time and payload-specific.
Side by side
| Property | PSD2 SCA dynamic linking | Cosignet payload binding |
|---|---|---|
| What the approval is bound to | Amount and payee | SHA-256 of the full action payload |
| Tamper resistance | Changing amount or payee invalidates the code | Changing any payload field invalidates the signature |
| Replay resistance | Code is transaction-specific | Challenge is one-time and payload-specific |
| What signs | Possession and inherence factors | WebAuthn passkey with user verification (biometrics, PIN, passcode, or security key, depending on the authenticator) |
| What the user sees | Amount and payee before authorizing | The exact action, re-hashed in the browser and confirmed against the signed fingerprint (WYSIWYS) |
Why a fintech reader cares
When an agent initiates or triggers a payment, the interesting compliance question is not "did the API call succeed." It is "was there a strong, non-repudiable authorization bound to the exact transaction, and can we prove it later." Dynamic linking answers the first half. Cosignet adds the second half: every payload-bound approval is recorded in an append-only, independently verifiable transparency log, so the authorization can be reconstructed and checked by a third party without trusting Cosignet. See how that supports DORA ICT traceability.
Where the analogy ends
To be exact about the limits:
- Cosignet is not a certified SCA solution and does not make your payment flows PSD2 compliant. Your SCA obligations, exemptions, and certifications remain yours.
- The construction is a design parallel. Whether it satisfies a specific regulatory requirement in your context is a question for your compliance function and counsel.
- Cosignet secures the authorization and its evidence, not the payment rails themselves.
Related reading
- DORA and AI agents: the audit trail an examiner asks for.
- Agent-initiated payments and treasury operations.
- For auditors: verify a real record end to end.
- All compliance mappings.
Bind approvals to the exact agent action
Free to start, no credit card.
Informational, not legal advice. This page draws a design analogy between PSD2 SCA dynamic linking and Cosignet's payload binding. It is not a legal opinion, and Cosignet is not a certified PSD2 or SCA solution. Verify all regulatory references against the primary sources linked above and confirm applicability with your own counsel.