A treasury payment agent can prepare or release a payment only when the request is authentic, every relevant party and route has current context, delegated authority is valid, sanctions and payment controls return an executable outcome, and any required checker approves the same bound instruction before expiry. A potential sanctions match, prohibited counterparty, invalid account, incomplete mandatory field, absolute authority breach, or unavailable mandatory control stops the release.
This guide answers one bounded implementation question: how to govern an agent action that prepares or releases a treasury payment. The governing AML and payments agents guide covers the wider pan-EU financial-crime operating model. This page maps one payment-release action from intake through the bank or payment rail and a Sealed Evidence Bundle. It uses allow, warn, require_approval, and block as policy outcomes. The examples are synthetic and carry no legal threshold. Source scope and freshness were reviewed on 28 July 2026. Confirm the law, sanctions programs, list sources, payment rules, contracts, and internal authority that apply to each legal entity and route.
End-to-end process map for one treasury payment release
The governed unit is one exact payment instruction. The sequence below names every actor, system, decision, approval, execution step, downstream outcome, and evidence artifact. Stable correlation and execution identifiers join the complete path.
- 1. Requester and source system submit the payment request. Treasury operations receives the instruction through an approved channel. The intake system records the requesting principal, source-system identity, message authentication or signature, source digest, request time, invoice or obligation reference, and immutable payment-request artifact.
- 2. Intake validates authenticity and completeness. The intake control confirms the approved source, template, signature or message authentication, required fields, and duplicate key. An invalid source or missing mandatory field returns block and records source-authenticity and validation artifacts.
- 3. The Process assembles payment context. It binds payer, payee, beneficiary, payer and beneficiary accounts, banks and intermediaries, jurisdictions, currency, amount, purpose, value date, cutoff, payment rail, and relevant before-state digests to the payment instruction.
- 4. Identity infrastructure authenticates the actors. The workforce identity provider authenticates the requester and any reviewer. The workload identity provider authenticates the service and agent. The authority service resolves delegated purpose, account scope, tool access, amount limits, environment, expiry, and the assigned Data Boundary.
- 5. The treasury payment agent prepares the proposed release. The agent reads approved fields, checks the request, calls approved screening and validation services, and proposes one
treasury.payment.releaseaction. It cannot approve itself, change authority, suppress evidence, or call the payment rail before a releasable outcome. - 6. Sanctions and watchlist systems screen the route. The screening service checks the payer, payee, beneficiary, banks, intermediaries, jurisdictions, and ownership or control facts against the organisation’s applicable list sources and records source, version, retrieval time, digest, query inputs, match result, and adjudication state.
- 7. Payment-control systems evaluate the instruction. Deterministic checks cover duplicate, counterparty and account state, data quality, amount and aggregate exposure, anomaly, velocity, cutoff, currency, value date, and payment-rail restrictions. Each result becomes a structured policy input and evidence artifact.
- 8. The KLA Policy Engine evaluates the complete context. Versioned policy returns allow, warn, require_approval, or block, with a decision ID, matched rules, reason codes, policy digest, inputs digest, and evaluation time. The strongest matching outcome controls execution.
- 9. Decision Desk holds requests that require approval. A Decision Request presents the exact payment, screening result, checks, uncertainty, policy reasons, maker identity, required checker roles, authority limits, expiry, and evidence digest. Eligible independent reviewers approve, reject, reassign, or escalate under the maker-checker and multi-party rules.
- 10. The release gate revalidates the bound instruction. The Process checks the action digest, payment fields, policy and list versions, reviewer identities, approval time, expiry, authority, cutoff, and current business state. Changed or stale context creates a new evaluation and Decision Request.
- 11. The bank gateway or payment rail executes the permitted call. The release service sends the bound instruction with an idempotency key. The bank or rail remains the payment executor and returns accepted, rejected, pending, settled, returned, or unknown status with its own reference.
- 12. Treasury operations reconciles the downstream outcome. The Process records the payment-rail receipt, before and after digests, settlement or return state, business outcome, retry status, and any recall, compensation, rollback, or incident reference.
- 13. Audit Trail and Lineage Explorer expose the ordered record. Request, authenticity, authority, screening, payment checks, policy, approval, tool, rail, outcome, revocation, and recovery events remain joined under one Lineage Record.
- 14. Evidence Room seals the evidence. A Sealed Evidence Bundle contains the ordered event population, source and screening artifacts, policy and human decisions, payment-rail receipt, privacy treatment, manifest, artifact hashes, record hashes, signatures, and independent verification result.
Bind payment context, agent authority, tools, and data
Payment screening and approval depend on accurate party and route data. Preserve the payer, payee, ultimate beneficiary, account identifiers, legal entities, banks, intermediaries, jurisdictions, currency, amount, purpose, invoices, value date, cutoff, payment rail, and source provenance. Tokenize or redact exported identifiers under a documented privacy policy while preserving stable joins.
Keep the agent identity, requesting principal, delegated user, service identity, and accountable owner separately attributable. Resolve the mandate at the release boundary: permitted payer accounts, payment classes, tools, destinations, fields, purpose, currency, amount and aggregate limits, environment, time window, and Data Boundary. An authenticated workload can still lack authority for this payment.
The payment agent may call only approved intake, screening, counterparty, treasury-ledger, policy, approval, and payment-gateway tools. Each tool call needs a canonical tool ID and version, audience or destination, arguments digest, request and completion time, result digest, and error or downstream-effect record.
- Source authenticity: verify the source-system identity, message authentication or signature, template, required-field set, request time, and source digest before policy evaluation.
- Party and account context: distinguish payer, payee, ultimate beneficiary, debtor account, creditor account, banks, intermediaries, and ownership or control facts.
- Jurisdiction and currency: record every jurisdiction that drives legal, sanctions, tax, exchange-control, data, cutoff, or rail policy, with the applicable currency and route.
- Delegated authority: bind the agent mandate to one purpose, payment class, account population, tool set, destination set, amount band, aggregate exposure, environment, and expiry.
- Data Boundary: expose only approved fields to the agent and screening service. Preserve original sensitive data in its authoritative system and export tokenized references where policy requires.
Permitted and prohibited actions
Define the agent’s authority as explicit operations. Drafting, checking, proposing, approving, and releasing carry different consequences. A reviewer’s approval cannot widen the agent’s underlying entitlement or convert an absolute prohibition into a permitted action.
| Action | Agent authority | Required control | Evidence |
|---|---|---|---|
| Read an approved payment request | Permitted inside the assigned Data Boundary and purpose | Authenticated source, assigned request, field allowlist, current mandate | Requester, agent, resource, purpose, fields, source digest, authority decision |
| Validate party, account, amount, currency, and route fields | Permitted with read-only validation tools | Versioned checks and fail-closed mandatory-field rules | Inputs digest, validation version, result, missing or conflicting fields |
| Run sanctions, watchlist, duplicate, anomaly, velocity, and cutoff checks | Permitted through approved services | Current source and rule versions, complete scoped inputs, recorded result | Service, list or rule version, query digest, result, time, adjudication |
| Prepare a payment instruction | Permitted within delegated purpose and accounts | Separate preparer identity and immutable proposed-action digest | Maker, payment context, action digest, creation time |
| Submit a bound payment release | Conditionally permitted after an executable policy outcome | Valid authority, current checks, required approvals, one-use capability, idempotency | Policy, approvals, action binding, tool receipt, downstream effect |
| Approve its own proposal or act as a checker | Prohibited | Identity comparison and independent-role enforcement | Blocked attempt, maker identity, required role, reason code |
| Change payee, beneficiary, account, amount, currency, purpose, or route after approval | Prohibited under the existing approval | Digest comparison and full re-evaluation for any material change | Change record, expired or cancelled approval, new policy result |
| Clear a potential sanctions match or alter screening evidence | Prohibited unless a distinct qualified adjudication role owns that decision | Separate sanctions-adjudication workflow and source evidence | Match evidence, adjudicator identity, authority, rationale, result |
| Create reviewer authority, disable controls, suppress evidence, or reuse approval | Prohibited | Denied administrative operations, single-use decision, immutable evidence path | Denied attempt, policy rule, security or incident reference |
| Release through an unapproved bank, rail, account, jurisdiction, or credential | Prohibited | Destination, audience, account, jurisdiction, and credential allowlists | Blocked call, evaluated destination, reason codes, credential reference |
Threshold and approval decision table
Configure bands from the organisation’s legal analysis, sanctions risk assessment, treasury mandate, counterparty risk, liquidity policy, payment-rail rules, and observed operating data. Keep each check independently visible. Apply the strongest result in this order: block, require_approval, warn, allow.
The table supplies testable control logic and contains no universal regulatory threshold. The synthetic samples use EUR 125,000 and EUR 48,000 solely to exercise local policy paths.
| Control input | allow | warn | require_approval | block |
|---|---|---|---|---|
| Amount and aggregate exposure | Inside the agent’s routine band and all per-payment, daily, account, entity, and currency limits | Near a local operating band or unusual against the approved schedule | Above maker authority and within named checker authority; multi-party rule applies when configured | Above absolute authority, liquidity, counterparty, account, currency, or legal limit |
| Sanctions and watchlists | All required screenings completed with current sources and a clear result | Permitted low-risk data-quality signal with defined follow-up under local policy | A local policy routes a resolvable potential match to a qualified sanctions adjudicator before any release decision | Confirmed prohibition, unresolved potential match under fail-closed policy, missing required source, stale source, or unavailable mandatory screening |
| Counterparty, beneficiary, and account | Approved party and account with current ownership, bank, jurisdiction, and purpose context | Known party with a bounded non-material change selected for follow-up | New beneficiary, changed account, elevated-risk jurisdiction, ownership change, or related-party condition inside approvable policy | Prohibited party, closed or invalid account, unapproved bank or rail, forbidden jurisdiction, or ownership facts required for screening are absent |
| Data quality and source authenticity | Approved source, valid authentication, complete fields, consistent identifiers, current supporting records | Complete request with a non-material normalization or freshness signal | Conflicting non-mandatory evidence that an authorised checker can resolve before release | Invalid source, failed signature, missing mandatory field, malformed amount or currency, conflicting beneficiary identity, or unverifiable instruction |
| Anomaly | Pattern fits the approved payment schedule, counterparty, amount, time, currency, and route | Bounded deviation inside current authority with a defined assurance follow-up | Novel pattern, unusual sequence, new route, out-of-hours request, or material model signal inside approvable limits | Known fraud indicator, uncontrolled model condition, prohibited sequence, or anomaly service required by policy is unavailable |
| Duplicate and idempotency | No duplicate key or prior equivalent release; one unused idempotency key | Possible upstream duplicate with evidence that release remains uniquely identified | Ambiguous prior request requires treasury operations to resolve before release | Confirmed duplicate, reused approval, reused idempotency key with inconsistent arguments, or prior successful effect |
| Velocity and cutoff | Inside per-agent, account, counterparty, entity, and rail velocity limits and before cutoff | Near a local velocity or cutoff band with sufficient settlement time | Elevated aggregate flow or approaching cutoff requires a named checker and current liquidity context | Absolute velocity breach, closed window, expired value date, or bank or rail unavailable under fail-closed policy |
Maker-checker responsibility matrix
Preparation, review, and release remain separate, testable duties. The payment preparer creates or sponsors the instruction. The checker independently reviews the bound evidence. The release service executes only the approved instruction. A sanctions adjudicator owns potential-match resolution when local policy permits that path.
Multi-party approval requires each named role to decide under current authority. Record sequence, independence, limits, evidence digest, decision, reason, and time for every checker. A partially approved request stays held.
| Activity | Payment preparer | Treasury checker | Sanctions adjudicator | Release service | Accountable owner |
|---|---|---|---|---|---|
| Authenticate source and assemble payment | Responsible | Reviews material exceptions | Consulted for screening fields | No action | Accountable for procedure |
| Run screening and deterministic controls | May initiate | Reviews results | Responsible for potential-match adjudication | Consumes final results | Accountable for assigned owners |
| Prepare proposed release | Responsible as maker | No field editing | No field editing | No action | Accountable for mandate |
| Approve amount or treasury exception | Ineligible for own request | Responsible within current authority | Consulted where screening context changes | No action | Accountable for approval policy |
| Resolve a potential sanctions match | Provides source facts | Receives result | Responsible under separate authority | No action while unresolved | Accountable for sanctions program |
| Release the bound instruction | No direct release when checker is required | Decision already recorded | Decision already recorded | Responsible for one idempotent call | Accountable for payment Process |
| Reconcile bank or rail outcome | Responsible for operations follow-up | Reviews material exception | Consulted for sanctions hold or release state | Records receipt | Accountable for final state |
| Revoke, contain, and recover | Supports reconciliation | Supports decision | Owns sanctions response actions | Stops calls and retries | Accountable for incident and restart |
Set approval expiry, reassignment, and escalation
Expiry is an authorization boundary. Set it from sanctions-list freshness, payment-context volatility, cutoff, exchange-rate and liquidity sensitivity, reviewer availability, and the safe hold window. The request remains held until every required checker decides.
Reassignment preserves the original assignee, reason, evidence, expiry, and history. The replacement must hold equal or greater authority for the payment class and current amount. Reassignment never resets expiry automatically.
Escalate before expiry to the role defined by policy. A potential sanctions match follows the sanctions-adjudication escalation path. A bank or rail outage follows payment-operations and resilience escalation. An expired request records expired, performs zero release tool calls, refreshes screening and payment context, evaluates policy again, and creates a new Decision Request.
| Condition | Queue action | Execution state | Evidence |
|---|---|---|---|
| Single checker required | Assign one eligible checker with authority for the payment class and amount | Held until approval; stopped on rejection or expiry | Role snapshot, maker comparison, decision, reason, time, evidence digest |
| Multi-party approval required | Assign every required role and preserve the configured sequence | Held until all approvals are current and complete | One record per checker, order, authority, independence, expiry |
| Assignee unavailable | Reassign to an eligible checker and retain the original assignment | Held under the original expiry | Previous assignee, new assignee, actor, reason, time |
| Approaching expiry | Escalate to the configured equal or higher authority | Held | Escalation actor, route, reason, time, remaining window |
| Expired or materially changed | Close the Decision Request and re-evaluate current context | Stopped; a new request is required | Expiry or change reason, zero tool calls, refreshed inputs, new decision ID |
Record the bank or payment-rail outcome
KLA records the governed decision and instrumented release call. The connected bank gateway or payment rail executes the payment and remains authoritative for acceptance, rejection, settlement, return, and recall state.
Use one idempotency key for one bound instruction. Record the arguments digest, destination, request time, bank or rail reference, response status and code, before and after digests, settlement or return state, and reconciliation source. A successful API response can still leave the business outcome pending or unknown.
Reconcile the payment against an independently obtained bank or rail source. Keep pending and unknown outcomes open. Route rejection, timeout, partial effect, return, or inconsistent retry to the defined operations or incident path. Capture every later state change under the same correlation and execution identifiers.
Map the event sequence to the public audit-event schema
The public AI Agent Audit Log Schema represents one governed action from request through policy, approval, execution, outcome, evidence, privacy handling, and integrity verification. The payment-specific screening and validation details remain artifacts referenced by digest from the common envelope.
| Sequence stage | Public schema field | Treasury payment record |
|---|---|---|
| Envelope and correlation | schema_version, audit_event.event_id, event_type, times, sequence, correlation | Stable event, correlation, execution, trace, and span identifiers for one payment instruction |
| Organisation and retention | audit_event.scope | Pseudonymous organisation reference, environment, region, retention class, legal hold |
| Request, maker, agent, and owner | audit_event.actors | Requester, delegated user, service identity, agent, accountable owner, and identity providers |
| Release versions | audit_event.components | Agent, model, prompt template, and orchestrator IDs, versions, and configuration digests |
| Bound payment proposal | audit_event.requested_action | Action, purpose, tokenized payment resource, Data Boundary, environment, amount, currency, requested time |
| Screening and payment controls | audit_event.policy plus evidence.artifacts[] | Policy decision and reasons reference artifacts for source authenticity, sanctions lists, screening, duplicates, anomaly, velocity, cutoff, counterparty, and data quality |
| Maker-checker decision | audit_event.approval | Decision Request, status, times, expiry, required role, evidence digest, reviewer, decision, reason, rationale, reassignment or exception |
| Release call and rail effect | audit_event.tool_calls[] | Tool and version, action, bank or rail destination, arguments digest, idempotency key, result, downstream effect and references |
| Business and recovery outcome | audit_event.execution | Execution status and times, achieved or unresolved business outcome, rollback, recall, return, compensation, or incident reference |
| Ordered record and artifacts | audit_event.lineage and audit_event.evidence | Lineage Record ID, ordered event IDs, manifest reference, artifact IDs, types, and content digests |
| Privacy handling | audit_event.privacy | Classification, tokenization or redaction status, JSON pointers, methods, and access policy |
| Integrity verification | integrity | RFC 8785 canonicalization, SHA-256 record hash, predecessor hash when used, Ed25519 signature, verifier, time, status, and failure codes |
Sanitized successful sample run
This synthetic example proposes a EUR 125,000 treasury payment release. The figure is illustrative. Sanctions and watchlist screening returns clear. The amount crosses a local maker-checker band, so policy returns require_approval. A synthetic senior treasury officer approves the same instruction before expiry. The release tool uses an idempotency key, the synthetic bank gateway returns an acceptance receipt, and integrity verification reports valid. Download the approved JSON sample.
{
"schema_version": "1.0.0",
"audit_event": {
"event_id": "evt_synthetic_treasury_approved_20260728",
"event_type": "agent.action.completed",
"occurred_at": "2026-07-28T09:15:08.481Z",
"recorded_at": "2026-07-28T09:15:08.612Z",
"sequence": 18,
"correlation": {
"correlation_id": "corr_synthetic_treasury_approved_20260728",
"execution_id": "run_synthetic_treasury_approved_20260728",
"trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
"span_id": "00f067aa0ba902b7"
},
"scope": {
"organization_ref": "orgref_synthetic_eu_treasury_01",
"environment": "production-eu",
"region": "eu-west",
"retention_class": "regulated-payment-7y",
"legal_hold": false
},
"actors": {
"requester": {
"id": "usr_synthetic_treasury_maker_017",
"type": "user",
"display_name": "Synthetic treasury payment preparer",
"identity_provider": "workforce-iam"
},
"delegated_user": {
"id": "usr_synthetic_treasury_maker_017",
"type": "user",
"identity_provider": "workforce-iam"
},
"service_identity": {
"id": "svc_synthetic_treasury_agent_prod",
"type": "service",
"identity_provider": "workload-identity"
},
"agent": {
"id": "agent_synthetic_treasury_release",
"type": "agent",
"display_name": "Synthetic treasury payment-release agent"
},
"accountable_owner": {
"id": "role_synthetic_head_treasury_operations",
"type": "organization",
"display_name": "Synthetic head of treasury operations"
}
},
"components": {
"agent": {
"id": "treasury-payment-release-agent",
"version": "release-2026.07.28.1",
"configuration_digest": "sha256:65b95530f15bb617be582f2cd23a9bc4e9f4144623a43975266a6f7ce1510a2f"
},
"model": {
"id": "treasury-payment-context-model",
"version": "2026-07-10",
"configuration_digest": "sha256:8721063842a566d2d48c8ffc912b370e13846d0c9a2665f72a62e153c791d14d"
},
"prompt_template": {
"id": "treasury-release-system-prompt",
"version": "5.3.0",
"configuration_digest": "sha256:dc675cfacd5001e356062d0c82bb2cf4ddfa8417929e0d7cfdc1a7bba9f6c300"
},
"orchestrator": {
"id": "treasury-payment-release-process",
"version": "14",
"configuration_digest": "sha256:4499ee0f6418cfde2095492fd15833425502d6c387f8c1c11e81c37a4a4b4f4c"
}
},
"requested_action": {
"action": "treasury.payment.release",
"purpose": "release-approved-treasury-payment",
"resource": {
"type": "payment_instruction",
"id": "payment_synthetic_20260728_0042"
},
"data_boundary_ref": "boundary_eu_treasury_restricted",
"environment": "production-eu",
"amount": {
"value": "125000.00",
"currency": "EUR"
},
"requested_at": "2026-07-28T09:14:29.122Z"
},
"policy": {
"decision_id": "dec_synthetic_treasury_approved_20260728",
"policy_id": "treasury-payment-release-policy",
"policy_version": "7.2.0",
"policy_digest": "sha256:dfb0b86f9e69ed9613e6c347632ff1bf0813eb570439e01a18cd7e56c686091b",
"inputs_digest": "sha256:f3b9e01da2e24bea435b44b4c312a6d05de54075bf992bd6bb0ed79a22c07bc0",
"decision": "require_approval",
"evaluated_at": "2026-07-28T09:14:29.188Z",
"matched_rule_ids": [
"sanctions-screening-clear",
"approved-beneficiary-and-account",
"maker-checker-above-local-band"
],
"reason_codes": [
"screening_clear",
"amount_requires_senior_treasury_checker"
]
},
"approval": {
"request_id": "dr_synthetic_treasury_approved_20260728",
"status": "decided",
"requested_at": "2026-07-28T09:14:29.214Z",
"expires_at": "2026-07-28T09:44:29.214Z",
"required_role": "senior_treasury_officer",
"presented_evidence_digest": "sha256:fe7d8a9a4b28878e66443038d1896ea748a00b748cbe7fdc3341479b891816fe",
"reviewer": {
"id": "usr_synthetic_senior_treasury_031",
"type": "user",
"display_name": "Synthetic senior treasury officer",
"identity_provider": "workforce-iam"
},
"decision": "approved",
"reason_code": "screening_and_payment_context_verified",
"rationale_reference": "decision-note-synthetic-tokenized-031",
"decided_at": "2026-07-28T09:15:07.902Z"
},
"tool_calls": [
{
"call_id": "call_synthetic_payment_rail_20260728",
"tool_id": "bank-gateway.payment-release",
"tool_version": "2026-07-20",
"action": "release_payment",
"destination": "synthetic-bank-rail-eu",
"requested_at": "2026-07-28T09:15:07.944Z",
"arguments_digest": "sha256:5e7c5f9b53ac522ecdc5f476176053e61d72a78b9475386f046c4a6bf04f2a48",
"idempotency_key": "run_synthetic_treasury_approved_20260728:release-payment",
"status": "succeeded",
"completed_at": "2026-07-28T09:15:08.433Z",
"result_digest": "sha256:4a2f28f803051c238f66e218eec02e65691556c4b4128d482d1f8dd90a081e77",
"downstream_effects": [
{
"system": "synthetic-bank-rail-eu",
"effect_type": "payment_instruction_accepted",
"effect_reference": "rail-receipt-synthetic-20260728-0042",
"before_state_digest": "sha256:a5f3c6a11b62647f2cc95e50befb5b8e7e4ad9fe4f374691ddd6610f16297109",
"after_state_digest": "sha256:0932e223fcb9c36ea2cee608b9c2135f5dba43cd73ea1d6d593b7e6091ef5135"
}
]
}
],
"execution": {
"status": "succeeded",
"started_at": "2026-07-28T09:15:07.920Z",
"completed_at": "2026-07-28T09:15:08.481Z",
"business_outcome": {
"status": "achieved",
"summary": "The synthetic bank gateway accepted the approved payment instruction and returned a rail receipt.",
"reference": "outcome_synthetic_payment_accepted_0042"
},
"rollback": {
"status": "not_required",
"reference": "rollback-policy-synthetic-treasury-release"
}
},
"lineage": {
"lineage_record_id": "lin_synthetic_treasury_approved_20260728",
"ordered_event_ids": [
"evt_synthetic_payment_intake_0042",
"evt_synthetic_screening_clear_0042",
"evt_synthetic_policy_approval_required_0042",
"evt_synthetic_checker_approved_0042",
"evt_synthetic_rail_accepted_0042",
"evt_synthetic_treasury_approved_20260728"
]
},
"evidence": {
"manifest_ref": "bundle_manifest_synthetic_treasury_approved_20260728",
"artifacts": [
{
"artifact_id": "artifact_synthetic_source_authenticity_0042",
"artifact_type": "payment-source-authenticity",
"content_digest": "sha256:6c793181b83d28123a27328a2a5d65ce8dbcbb56f923649d7b43a22a9303c76d"
},
{
"artifact_id": "artifact_synthetic_sanctions_clear_0042",
"artifact_type": "sanctions-screening-result",
"content_digest": "sha256:a17aaf56c5bd7c85dc8e3d49c74ea01c79749668be8e93b3b2bf57c3908f27f3"
},
{
"artifact_id": "artifact_synthetic_approval_0042",
"artifact_type": "approval-decision",
"content_digest": "sha256:0859f92f8b7ec439bc004baad8b4fc93851c14bf0de8a3511619882e2d1db43b"
},
{
"artifact_id": "artifact_synthetic_rail_receipt_0042",
"artifact_type": "payment-rail-receipt",
"content_digest": "sha256:f27fede2220bcd326aee3bcff314c4dccfa3e5d5cb8b9287d06d654345ae29cd"
}
]
},
"privacy": {
"classification": "restricted",
"redaction_status": "tokenized",
"redactions": [
{
"json_pointer": "/actors/requester/id",
"method": "tokenized"
},
{
"json_pointer": "/requested_action/resource/id",
"method": "tokenized"
}
],
"access_policy_ref": "evidence-access-synthetic-regulated-treasury"
}
},
"integrity": {
"canonicalization": "RFC8785-JCS",
"hash_algorithm": "SHA-256",
"record_hash": "sha256:6f1d65f09f7bd8eea22bc06c76d58b9a983ab9066232f025245c5c5bee5f937d",
"signature": {
"algorithm": "Ed25519",
"key_id": "synthetic-treasury-sample-key-2026-01",
"public_key_spki": "MCowBQYDK2VwAyEAUENkPpZZtnjq0OZHXSf2GV7zpmIvHrd6L8LrONvUn8o=",
"value": "Ue+Naudajb+Tmv/Qm+k8c2p+SfVC/RKb9Xp6uWd9jyeZTVJnFrFxLXYJXAp2UZ4SpwAsNnAbYSCnuh90ghN8Cw=="
},
"verification": {
"status": "valid",
"verified_at": "2026-07-28T09:15:09.041Z",
"verifier": {
"id": "vendor-neutral-reference-verifier",
"version": "1.0.0"
},
"failure_codes": []
}
}
}Blocked sanctions negative run
This synthetic example records a potential sanctions and watchlist match against the beneficiary context. Policy returns block with the reason codes sanctions_watchlist_hit and beneficiary_requires_sanctions_adjudication. The event carries zero tool calls, execution remains not_started, and the payment stays unreleased. Download the sanctions-block JSON sample.
{
"schema_version": "1.0.0",
"audit_event": {
"event_id": "evt_synthetic_treasury_sanctions_block_20260728",
"event_type": "agent.action.denied",
"occurred_at": "2026-07-28T11:03:18.092Z",
"recorded_at": "2026-07-28T11:03:18.144Z",
"sequence": 5,
"correlation": {
"correlation_id": "corr_synthetic_treasury_sanctions_block_20260728",
"execution_id": "run_synthetic_treasury_sanctions_block_20260728",
"trace_id": "0af7651916cd43dd8448eb211c80319c",
"span_id": "b7ad6b7169203331"
},
"scope": {
"organization_ref": "orgref_synthetic_eu_treasury_01",
"environment": "production-eu",
"region": "eu-west",
"retention_class": "regulated-payment-denial-7y",
"legal_hold": false
},
"actors": {
"requester": {
"id": "usr_synthetic_treasury_maker_024",
"type": "user",
"display_name": "Synthetic treasury payment preparer",
"identity_provider": "workforce-iam"
},
"service_identity": {
"id": "svc_synthetic_treasury_agent_prod",
"type": "service",
"identity_provider": "workload-identity"
},
"agent": {
"id": "agent_synthetic_treasury_release",
"type": "agent",
"display_name": "Synthetic treasury payment-release agent"
},
"accountable_owner": {
"id": "role_synthetic_head_treasury_operations",
"type": "organization",
"display_name": "Synthetic head of treasury operations"
}
},
"components": {
"agent": {
"id": "treasury-payment-release-agent",
"version": "release-2026.07.28.1",
"configuration_digest": "sha256:65b95530f15bb617be582f2cd23a9bc4e9f4144623a43975266a6f7ce1510a2f"
},
"model": {
"id": "treasury-payment-context-model",
"version": "2026-07-10",
"configuration_digest": "sha256:8721063842a566d2d48c8ffc912b370e13846d0c9a2665f72a62e153c791d14d"
},
"prompt_template": {
"id": "treasury-release-system-prompt",
"version": "5.3.0",
"configuration_digest": "sha256:dc675cfacd5001e356062d0c82bb2cf4ddfa8417929e0d7cfdc1a7bba9f6c300"
},
"orchestrator": {
"id": "treasury-payment-release-process",
"version": "14",
"configuration_digest": "sha256:4499ee0f6418cfde2095492fd15833425502d6c387f8c1c11e81c37a4a4b4f4c"
}
},
"requested_action": {
"action": "treasury.payment.release",
"purpose": "release-approved-treasury-payment",
"resource": {
"type": "payment_instruction",
"id": "payment_synthetic_20260728_0099"
},
"data_boundary_ref": "boundary_eu_treasury_restricted",
"environment": "production-eu",
"amount": {
"value": "48000.00",
"currency": "EUR"
},
"requested_at": "2026-07-28T11:03:18.021Z"
},
"policy": {
"decision_id": "dec_synthetic_treasury_sanctions_block_20260728",
"policy_id": "treasury-payment-release-policy",
"policy_version": "7.2.0",
"policy_digest": "sha256:dfb0b86f9e69ed9613e6c347632ff1bf0813eb570439e01a18cd7e56c686091b",
"inputs_digest": "sha256:36cdde251024f5c6ba4a69127ee16b4fddbd3c2101995d9d8d0a135c54a9f16e",
"decision": "block",
"evaluated_at": "2026-07-28T11:03:18.081Z",
"matched_rule_ids": [
"sanctions-watchlist-potential-match",
"payment-release-fail-closed"
],
"reason_codes": [
"sanctions_watchlist_hit",
"beneficiary_requires_sanctions_adjudication"
]
},
"tool_calls": [],
"execution": {
"status": "not_started",
"business_outcome": {
"status": "not_achieved",
"summary": "The synthetic payment instruction remained unreleased because sanctions screening produced a potential match.",
"reference": "outcome_synthetic_sanctions_block_0099"
}
},
"lineage": {
"lineage_record_id": "lin_synthetic_treasury_sanctions_block_20260728",
"ordered_event_ids": [
"evt_synthetic_payment_intake_0099",
"evt_synthetic_sanctions_match_0099",
"evt_synthetic_policy_block_0099",
"evt_synthetic_treasury_sanctions_block_20260728"
]
},
"evidence": {
"manifest_ref": "bundle_manifest_synthetic_treasury_sanctions_block_20260728",
"artifacts": [
{
"artifact_id": "artifact_synthetic_source_authenticity_0099",
"artifact_type": "payment-source-authenticity",
"content_digest": "sha256:51621194f1179592adf5b28ed1273d74ea8a3e215563cad3134bc67c5b2e8484"
},
{
"artifact_id": "artifact_synthetic_sanctions_match_0099",
"artifact_type": "sanctions-screening-result",
"content_digest": "sha256:40bb1e4f2cfdad1809979b5768bab770c18cfef2c96fe74bd0458952a30a6858"
},
{
"artifact_id": "artifact_synthetic_policy_block_0099",
"artifact_type": "policy-decision",
"content_digest": "sha256:3dd5603753882085593a880d61c92e65e0ec758253c810b23e08dc7ba4cf2a32"
}
]
},
"privacy": {
"classification": "restricted",
"redaction_status": "tokenized",
"redactions": [
{
"json_pointer": "/actors/requester/id",
"method": "tokenized"
},
{
"json_pointer": "/requested_action/resource/id",
"method": "tokenized"
}
],
"access_policy_ref": "evidence-access-synthetic-regulated-treasury"
}
},
"integrity": {
"canonicalization": "RFC8785-JCS",
"hash_algorithm": "SHA-256",
"record_hash": "sha256:8d2eba7b69efc2cc5c78ffea6aa25abd93ffb4ceed8ba51801227bd4d27158c4",
"signature": {
"algorithm": "Ed25519",
"key_id": "synthetic-treasury-sample-key-2026-01",
"public_key_spki": "MCowBQYDK2VwAyEAUENkPpZZtnjq0OZHXSf2GV7zpmIvHrd6L8LrONvUn8o=",
"value": "9ARCGoapZmSSOlMss+P7S9UCkYYg1P9almO1s66dfqoLSrd+nln/J8hFoxFCf3DKW9A5Fg4TrFCRkKeljSDdBw=="
},
"verification": {
"status": "valid",
"verified_at": "2026-07-28T11:03:18.311Z",
"verifier": {
"id": "vendor-neutral-reference-verifier",
"version": "1.0.0"
},
"failure_codes": []
}
}
}Failure modes and recovery
Test the complete path under malformed requests, stale lists, identity changes, queue failures, retries, rail outages, partial effects, and incident recovery. Keep the Process in a defined safe state until downstream reconciliation and required evidence complete.
| Failure mode | Immediate control | Recovery path | Evidence |
|---|---|---|---|
| Unauthentic, malformed, or incomplete payment request | Return block before screening or release | Correct the source instruction and submit a new request | Source identity, failed field or signature, decision, new request reference |
| Sanctions list, screening service, or required data unavailable | Apply the configured fail-closed block | Restore or replace the approved source, rescreen every party and route, re-evaluate policy | Dependency status, source version, outage, refreshed screening, new decision |
| Potential or confirmed sanctions match | Keep the payment unreleased and revoke any pending release capability | Route potential matches to the qualified adjudication Process; follow applicable blocking, rejection, reporting, or release procedure | Match inputs, list and program, adjudicator, legal basis, disposition, regulator or incident reference when applicable |
| Duplicate request or reused idempotency key | Block inconsistent reuse and query the bank or rail for the prior outcome | Reconcile the original instruction; create a new unique instruction only under the approved procedure | Duplicate keys, arguments digests, prior receipt, reconciliation decision |
| Reviewer unavailable or conflict found | Hold the request | Reassign or escalate to an eligible checker within the original expiry | Conflict result, assignments, reason, authority snapshots, times |
| Approval expires or payment context changes | Invalidate release authority and perform zero tool calls | Refresh source, screening, account, amount, cutoff, policy, and identity context; issue a new Decision Request | Expiry or change, closed approval, refreshed inputs, new decision |
| Bank or rail rejects the instruction | Record the rejected downstream effect and stop automatic retries that change arguments | Correct the cause through a new governed instruction or close the payment | Rail reference, code, receipt, owner decision, replacement request |
| Timeout leaves downstream state unknown | Prevent a second side effect with the same idempotency contract | Query the authoritative bank or rail, reconcile accepted or absent state, escalate unresolved status | Timeout, idempotency key, inquiry result, final state, incident when required |
| Partial or incorrect downstream effect | Contain retries, revoke release authority, open an incident | Use the applicable cancellation, recall, return, compensation, or manual reconciliation path | Committed effects, residue, incident, recovery actions, final business outcome |
| Agent, credential, policy, or screening compromise | Disable the agent, revoke credentials, deny tool calls, freeze affected queues | Scope the population, reconcile downstream effects, restore trusted Releases and sources, test controls, approve restart | Revocation results, affected executions, investigation, remediation, test, restart decision |
| Required evidence cannot be written or sealed | Hold or block the action under the evidence contract | Restore evidence services, reconcile every affected request, seal complete records before release or close as a control failure | Write failure, affected population, reconciliation, completed bundle or exception |
Retain and export payment-release evidence
Retain the complete population under a jurisdiction, legal-hold, privacy, and records schedule approved by the organisation. The downloadable evidence bundle manifest lists the ordered events and artifacts for one payment release. It also links both samples, the public schema, and the offline verification steps for an individual record and the bundle-level manifest seal.
A Sealed Evidence Bundle should contain source-authenticity proof, payment context, authority and version records, screening source and result, every payment-control result, policy and approval records, the exact tool-call receipt, bank or rail outcome, reconciliation, incidents or recovery, ordered lineage, privacy treatment, artifact digests, record hashes, signatures, and verification results.
An examiner can validate the JSON Schema, recompute record and artifact hashes, verify signatures, reconstruct ordering, test that approval preceded release, confirm a blocked action reached no tool, compare idempotency keys with downstream effects, and reconcile the payment-rail receipt with an independently obtained source.
Implementation checklist
Use the treasury payment agent release checklist to complete the control design for one action. It covers payment intake and source authenticity; payer, payee, beneficiary, accounts, jurisdictions, currency, and amount; identity and delegated authority; tool access and Data Boundaries; screening sources; duplicate, anomaly, velocity, cutoff, and threshold rules; duty separation; permitted and prohibited actions; maker-checker and multi-party approval; expiry, reassignment, and escalation; downstream outcomes; rejection, rollback, incident, and revocation; evidence retention and export; and final sign-off.
- Scope one instruction. Name the payment class, legal entities, accounts, currencies, jurisdictions, rail, purpose, agent, requester, owner, tools, and evidence contract.
- Approve source and context rules. Define authentic channels, mandatory fields, party and account sources, data freshness, duplicate keys, and privacy treatment.
- Approve screening sources. Record the applicable legal scope, lists or vendor data, update and digest rules, screened entities, potential-match policy, and outage behavior.
- Publish decision bands. Give every amount, counterparty, data-quality, anomaly, duplicate, velocity, cutoff, currency, and route condition an explicit outcome and reason code.
- Test separation. Prove the maker cannot approve or release its held request, every checker holds current authority, and changed context invalidates approval.
- Test positive and negative paths. Validate allowed, warned, approved, rejected, expired, blocked, duplicate, outage, rail rejection, unknown outcome, partial effect, revocation, and recovery cases.
- Verify evidence offline. Validate the schema, hashes, signatures, event order, approval timing, tool receipts, downstream state, and retention metadata.
- Sign off and review. Obtain treasury, sanctions compliance, financial crime, IAM, payment operations, technical, risk, and assurance approvals with a next-review date.
How KLA implements the treasury payment control path
The KLA Control Plane shipped policy, approval, lineage, audit, and evidence capabilities for instrumented agent actions. The KLA Policy Engine evaluates the proposed treasury release and its current identity, authority, screening, amount, counterparty, data-quality, anomaly, duplicate, velocity, cutoff, currency, route, and evidence context. It returns allow, warn, require_approval, or block. A require_approval outcome holds the bound call and creates a Decision Request for Decision Desk. A block prevents the governed payment call from reaching the bank gateway or payment rail.
For control-plane Decision Requests, Decision Desk checks decision permission, the required reviewer role, pending state, requester and maker identity, and due time. It prevents recorded requesters and makers from deciding their own request and rejects approve or reject actions after the due time. An eligible checker can escalate an overdue request. The organisation must supply current maker identities, required roles, due time, and complete payment and screening evidence on every producing path.
Lineage Explorer and Audit Trail expose policy, human-decision, tool, execution, and downstream-effect records. Evidence Room can package selected records into a Sealed Evidence Bundle with artifact hashes, signatures, and a Merkle root that supports offline integrity checks.
The bank or payment-rail system executes the payment and owns its settlement state. The sanctions-list authority or screening vendor supplies the list data and match service. The workforce IAM and workload-identity providers authenticate people, services, and agent workloads. KLA supplies the instrumented policy, Decision Desk, lineage, audit, and evidence control path around the action. The organisation still owns legal and sanctions analysis, list and screening quality, payment classification, data completeness, thresholds, reviewer competence and staffing, identity and entitlement administration, bank and rail connectivity, liquidity and cutoff rules, retention, complete instrumentation, incident response, recovery, and reconciliation.
Primary sources and freshness
Source review completed 28 July 2026. Sanctions programs, designations, regulations, payment standards, payment-rail rules, and institutional policies change. Recheck the live source, applicable program, local legal analysis, and bank or rail rulebook before using a control decision.
For United States jurisdiction, the OFAC Sanctions List Service provides current SDN and non-SDN list data. OFAC’s Framework for OFAC Compliance Commitments recommends a risk-based sanctions compliance program built around management commitment, risk assessment, internal controls, testing and auditing, and training for organisations subject to U.S. jurisdiction and relevant foreign dealings. Applicable OFAC program rules determine whether an organisation blocks, rejects, reports, or may process a transaction.
For European Union scope, the European Commission’s sanctions overview and consolidated financial sanctions list reflects adopted EU legal acts and is updated as necessary. Regulation (EU) 2023/1113 applies within its stated transfer-of-funds and crypto-asset scope where a covered provider is established in the Union; it addresses payer, payee, account or transaction-identifier information, verification, missing information, restrictive-measures controls, and retention. The regulation supplies legal requirements for covered providers. Each organisation must map its legal role and payment route.
For United Nations measures, the UN Security Council Consolidated List aggregates listed individuals and entities. Member States implement the measures attached to each applicable Security Council sanctions regime. The organisation must determine the relevant national implementation and measure for its jurisdiction and transaction.
At the international standards level, the June 2025 FATF Recommendation 16 update addresses responsibilities in the payment chain, standardized cross-border payment information, and tools that protect against fraud and error; FATF stated that the revised changes come into effect by the end of 2030. Jurisdictions implement FATF standards, and each organisation sets enterprise payment thresholds for its applicable legal, contractual, risk, and authority context.
As industry guidance, the Wolfsberg Payment Transparency Standards address cross-border and applicable domestic payments, participating payment service providers, payment-message party information, and the ability of parties in the chain to monitor and screen effectively. The Wolfsberg AI and machine learning principles place responsibility for financial-crime uses with the financial institution and address legitimate purpose, proportionate use, design and technical expertise, accountability and oversight, and openness and transparency.
For covered EU financial entities, DORA, Regulation (EU) 2022/2554 requires a documented ICT risk management framework, governance, resilience, incident, testing, and third-party controls within its scope. For an AI system that falls within the EU AI Act’s high-risk scope, Article 14 requires effective human oversight proportionate to risk, autonomy, and context, including monitoring, interpretation, override, reversal, intervention, and safe interruption capabilities. System classification and legal role determine whether Article 14 applies.
The four-outcome model, synthetic amount bands, maker-checker design, event mapping, samples, checklist, and bundle manifest in this guide are implementation patterns. They carry no universal legal, sanctions, accounting, liquidity, or payment-rail threshold.
Frequently Asked Questions
Can an AI agent release a treasury payment?
An organisation can authorize a payment agent to submit a release only inside an explicit mandate, after required source, identity, sanctions, counterparty, amount, data-quality, anomaly, duplicate, velocity, cutoff, currency, and route controls return an executable outcome. Required human approvals must cover the same current instruction.
Which parties should sanctions screening cover?
Screen the parties and route required by the applicable legal and institutional policy. The control design commonly records the payer, payee, ultimate beneficiary, banks, intermediaries, jurisdictions, and relevant ownership or control facts, together with list sources and versions.
How should maker-checker separation work for a payment agent?
Record the payment preparer as maker, route the bound request to independent eligible checkers, prohibit the maker and agent from deciding their own request, keep field editing separate from approval, and let the release service execute only after every required decision is current.
When should a treasury payment require approval?
Require approval for conditions that exceed maker authority and remain within an eligible checker’s authority, such as configured amount or aggregate bands, a new beneficiary, changed account, elevated-risk route, anomaly, approaching cutoff, or other material exception. Legal prohibitions and absolute authority breaches remain blocked.
What happens when a sanctions screen returns a potential match?
Keep the payment unreleased under the organisation’s fail-closed rule and route the match to a qualified sanctions adjudication process when local policy permits adjudication. Preserve the source, list version, query inputs, match evidence, authority, decision, rationale, and resulting legal or operational action.
What happens when payment approval expires?
Expiry invalidates release authority. Record the expired Decision Request with zero release tool calls, refresh screening and payment context, evaluate current policy, and create a new request when the payment remains eligible.
How do idempotency and duplicate checks differ?
Duplicate controls compare business instructions, invoices, parties, accounts, amounts, dates, and prior effects. An idempotency key constrains retries of one bound tool call. Use both controls and reconcile ambiguous outcomes with the authoritative bank or payment rail.
What proves that approval preceded the payment release?
Use ordered event IDs and timestamps for request, policy, approval, tool call, and completion. Bind the action and presented evidence with digests, record reviewer authority and expiry, attach the rail receipt, and verify the signed event and artifact hashes.
Does KLA provide sanctions lists or execute payments?
KLA governs an instrumented action through policy, Decision Desk, lineage, audit, and evidence controls. The selected sanctions authority or screening vendor supplies list data and screening. The bank gateway or payment rail executes and settles the payment. Identity providers authenticate people and workloads.
What belongs in a treasury payment evidence bundle?
Include source authenticity, payment and party context, identity and authority, component versions, screening sources and results, payment-control results, policy, every human decision, tool receipt, rail outcome, reconciliation, incidents or recovery, ordered lineage, privacy treatment, retention, artifact digests, record hashes, signatures, and verification results.
Key Takeaways
A governed treasury payment release binds an authentic instruction, complete party and route context, current agent authority, sanctions and payment-control results, independent human decisions, one idempotent bank or rail call, the downstream outcome, and verifiable evidence. Start with the treasury payment agent release checklist, validate the approved sample and sanctions-block sample against the public schema, and use the evidence bundle manifest for offline review.