PAYMENTS SIGNAL REFERENCE ARCHITECTURE · SYNTHETIC / TRAINING ONLY

Payment security, trust boundaries, entitlements, observability, continuity, and recovery

Treat identity, change, secrets, network boundaries, telemetry, continuity, and payment-safe recovery as one control architecture.

Payments Signal reference architecture v1 · reviewed 2026-07-23

Reference architecture—not a scheme mandate. This blueprint shows control responsibilities around payment execution and recovery. It does not define a threat model, cryptographic suite, security-zone count, cloud pattern, recovery target, privileged-access product, data-residency rule, regulatory obligation, or certification outcome for a particular institution.

Audience and purpose

Security, payment, cloud, infrastructure, operational-resilience, risk, audit, and service-management architects.

Components

Workforce, workload, and participant identity

Issues and verifies distinct identities for people, services, devices, counterparties, and network participants.

Kind
security
Owner
Identity and access management
Responsibilities
  • Use the right identity type for each actor
  • Bind authentication strength to payment risk
Inputs
  • Authorised business instruction and correlated state
Outputs
  • Versioned result, status, and audit evidence
Controls
  • Phishing-resistant privileged access
  • Certificate lifecycle
  • No shared production identity
Failure modes
  • Stolen credential
  • Expired certificate
  • Orphan service account
Recovery
  • Revoke and rotate
  • Contain affected sessions
  • Re-establish trust from verified identity
Non-functional requirements
  • Durable correlation through stable business and technical identifiers
  • Capacity and availability matched to the service-level objective
  • Auditable state changes, configuration, and operator actions

Entitlements and payment authority

Translates job, service, participant, amount, product, and context into an allowed payment action.

Kind
control
Owner
Payment control owner and access governance
Responsibilities
  • Separate create, approve, release, repair, and administer authority
  • Apply least privilege and segregation of duties
Inputs
  • Authorised business instruction and correlated state
Outputs
  • Versioned result, status, and audit evidence
Controls
  • Maker-checker
  • Context and amount limits
  • Periodic recertification
  • Emergency access review
Failure modes
  • Self-approval
  • Dormant privilege
  • Service can bypass payment gate
Recovery
  • Remove access
  • Review affected actions
  • Correct the control path before reopening
Non-functional requirements
  • Durable correlation through stable business and technical identifiers
  • Capacity and availability matched to the service-level objective
  • Auditable state changes, configuration, and operator actions

API, message, file, and network security boundary

Authenticates, authorises, validates, rate-limits, and records traffic crossing each trust boundary.

Kind
gateway
Owner
Platform and network security
Responsibilities
  • Protect every ingress and egress contract
  • Keep external, partner, user, and internal trust zones distinct
Inputs
  • Authorised business instruction and correlated state
Outputs
  • Versioned result, status, and audit evidence
Controls
  • Mutual authentication
  • Integrity and replay control
  • Schema and size limits
  • Denial-of-service protection
Failure modes
  • Spoofed participant
  • Replay
  • Malicious file
  • Boundary unavailable
Recovery
  • Reject before business processing
  • Isolate and recover the affected channel
  • Use tested alternate paths only
Non-functional requirements
  • Durable correlation through stable business and technical identifiers
  • Capacity and availability matched to the service-level objective
  • Auditable state changes, configuration, and operator actions

Cryptographic keys, secrets, and signing service

Protects key material and performs controlled signing, verification, encryption, and rotation.

Kind
security
Owner
Cryptographic security and key custodians
Responsibilities
  • Keep raw key material outside application memory where required
  • Prove key use, version, and authority
Inputs
  • Authorised business instruction and correlated state
Outputs
  • Versioned result, status, and audit evidence
Controls
  • Hardware-backed control where required
  • Dual control
  • Rotation and revocation
  • Usage audit
Failure modes
  • Key compromise
  • Signing unavailable
  • Expired trust chain
Recovery
  • Revoke and rotate
  • Stop affected message release
  • Revalidate trust and replay only authorised work
Non-functional requirements
  • Durable correlation through stable business and technical identifiers
  • Capacity and availability matched to the service-level objective
  • Auditable state changes, configuration, and operator actions

Hardened payment runtime and data stores

Runs payment services with isolation, secure configuration, immutable deployment evidence, backup, and recoverable state.

Kind
infrastructure
Owner
Platform engineering and data owners
Responsibilities
  • Separate environments and duties
  • Protect payment, personal, credential, and audit data by classification
Inputs
  • Authorised business instruction and correlated state
Outputs
  • Versioned result, status, and audit evidence
Controls
  • Approved image and dependency
  • Encrypted storage
  • Patch and configuration evidence
  • Backup integrity
Failure modes
  • Compromised runtime
  • Configuration drift
  • Corrupt backup
Recovery
  • Isolate workload
  • Restore from a verified point
  • Reconcile payment state before traffic resumes
Non-functional requirements
  • Durable correlation through stable business and technical identifiers
  • Capacity and availability matched to the service-level objective
  • Auditable state changes, configuration, and operator actions

Security and payment observability

Correlates logs, metrics, traces, business events, control outcomes, and settlement checkpoints without copying secrets or full payment data unnecessarily.

Kind
data-store
Owner
Security operations and payment service management
Responsibilities
  • Detect abnormal technical and payment behaviour
  • Keep telemetry useful, minimised, time-aligned, and tamper-evident
Inputs
  • Authorised business instruction and correlated state
Outputs
  • Versioned result, status, and audit evidence
Controls
  • Clock synchronisation
  • Immutable audit
  • Sensitive-data minimisation
  • Alert ownership
Failure modes
  • Blind spot
  • False alert flood
  • Sensitive data in logs
Recovery
  • Restore telemetry
  • Contain and redact exposed data
  • Reconstruct from retained business evidence
Non-functional requirements
  • Durable correlation through stable business and technical identifiers
  • Capacity and availability matched to the service-level objective
  • Auditable state changes, configuration, and operator actions

Continuity, backup, and recovery orchestration

Coordinates alternate capacity, dependency recovery, queue control, data restoration, and staged service reopening.

Kind
operations
Owner
Operational resilience and service owner
Responsibilities
  • Define recovery order and dependency map
  • Protect payment correctness while restoring service
Inputs
  • Authorised business instruction and correlated state
Outputs
  • Versioned result, status, and audit evidence
Controls
  • Tested recovery objective
  • Isolated recovery copy
  • Queue and ledger checkpoint
  • Business validation
Failure modes
  • Failover duplicates payments
  • Dependency recovers out of order
  • Backup cannot restore
Recovery
  • Freeze replay
  • Recover to a consistent boundary
  • Reconcile before staged reopen
Non-functional requirements
  • Durable correlation through stable business and technical identifiers
  • Capacity and availability matched to the service-level objective
  • Auditable state changes, configuration, and operator actions

Risk, change, testing, and assurance

Owns threat, control, dependency, test, exception, incident, and improvement evidence.

Kind
operations
Owner
Payment risk, security governance, architecture, and audit
Responsibilities
  • Assess changes and third parties
  • Test cyber, continuity, fraud, access, and payment-safe recovery
Inputs
  • Authorised business instruction and correlated state
Outputs
  • Versioned result, status, and audit evidence
Controls
  • Independent assurance
  • Change approval
  • Penetration and resilience testing
  • Exception expiry
Failure modes
  • Risk accepted without owner
  • Test excludes settlement and reconciliation
  • Known weakness never closes
Recovery
  • Escalate and time-bound
  • Retest end to end
  • Track corrective action to evidence
Non-functional requirements
  • Durable correlation through stable business and technical identifiers
  • Capacity and availability matched to the service-level objective
  • Auditable state changes, configuration, and operator actions

Interfaces

Authenticated identity and context

sec-identities → sec-entitlements

Supply verified human, service, device, or participant identity.

Contract
control · synchronous
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Deny unknown, expired, or weakly authenticated identity.

Authorised payment capability

sec-entitlements → sec-boundary

Constrain which interface and action the identity may use.

Contract
control · synchronous
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Reject unauthorised actions before payload processing.

Signing and trust service

sec-secrets → sec-boundary

Sign or verify the boundary exchange under current keys.

Contract
control · synchronous
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Stop release when signature or trust status is uncertain.

Validated payment traffic

sec-boundary → sec-platform

Admit only authenticated, authorised, intact, bounded traffic.

Contract
message · asynchronous
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Quarantine invalid or replayed traffic.

Technical and business telemetry

sec-platform → sec-observability

Emit correlated events and control outcomes without avoidable sensitive content.

Contract
event · asynchronous
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Buffer critical audit evidence during telemetry degradation.

Boundary security event

sec-boundary → sec-observability

Record authentication, authorisation, validation, and rate decisions.

Contract
event · asynchronous
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Preserve boundary evidence locally when the central sink is unavailable.

Incident and recovery signal

sec-observability → sec-continuity

Trigger owned response from proven service and payment symptoms.

Contract
event · asynchronous
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Escalate blind spots and conflicting signals.

Controlled recovery action

sec-continuity → sec-platform

Restore dependency, state, queue, and traffic in an approved order.

Contract
control · operator
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Block replay until idempotency and ledger state are proven.

Access policy and review

sec-governance → sec-entitlements

Publish approved roles, limits, recertification, and emergency-access policy.

Contract
control · batch
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Remove expired or unsupported privilege.

Tested recovery requirement

sec-governance → sec-continuity

Set and evidence recovery scenarios, objectives, dependencies, and lessons.

Contract
control · operator
Controls
  • Authentication and authorisation
  • Integrity and replay protection
  • Correlation and audit evidence
Failure treatment
Keep production enablement gated when the test cannot prove payment correctness.

Authored traces

Trusted release and recoverable evidence

Follow the controls that authenticate, authorise, protect, observe, and safely recover one payment action.

  1. Establish identity — Actor authenticated. A human, service, or participant presents current verifiable identity.
  2. Prove authority — Action authorised. Role, amount, service, product, and context permit this exact action.
  3. Protect integrity — Trust material current. Signing and verification use controlled key material and current trust.
  4. Validate the boundary — Traffic admitted. Identity, authority, integrity, replay, schema, and size checks pass.
  5. Process in a controlled runtime — Payment action recorded. The runtime uses protected state and emits a correlated business event.
  6. Observe the outcome — Control evidence retained. Security and payment telemetry can reconstruct the action without exposing unnecessary data.
  7. Keep recovery payment-safe — Recovery boundary known. If service fails, queue, ledger, and settlement state govern staged reopening.

Stress cases

Privileged credential is compromised

A privileged identity is suspected of unauthorised payment or configuration action.

Last confirmed state
Identity and action history exist; legitimacy is uncertain.
Settlement
Settlement varies by each affected payment and must be traced.
Funds and entries
Books and external movements must be reviewed individually.
Next owner
Security incident command and payment control owner
Safe action
Revoke access, contain sessions, freeze affected authority, and trace every action to payment and settlement evidence.
Evidence required
  • Authentication events
  • Entitlement history
  • Configuration changes
  • Payment and ledger references
Recovery
  • Rotate credentials
  • Review and correct unauthorised actions
  • Revalidate controls before restoring access

Signing service is unavailable

Outbound network messages cannot be signed with current trusted keys.

Last confirmed state
Payments may be approved internally but cannot cross the protected boundary.
Settlement
External settlement has not been initiated for queued messages.
Funds and entries
Internal reservations or postings depend on product design.
Next owner
Network security and payment operations
Safe action
Queue securely and invoke only the approved alternate signing or connectivity path.
Evidence required
  • Key status
  • Queued message hashes
  • Approval and cut-off
  • Alternate-path authority
Recovery
  • Restore trusted signing
  • Revalidate queued messages and authority
  • Release once with original identifiers

Failover restores a stale queue

The recovery site has an earlier queue checkpoint than the ledger or network.

Last confirmed state
Ledger and network may be ahead of the restored queue.
Settlement
Some payments may already be settled.
Funds and entries
Replaying the queue could duplicate value.
Next owner
Incident command, ledger, and payment operations
Safe action
Stop replay and reconcile business keys across queue, ledger, network, and statements.
Evidence required
  • Recovery checkpoint
  • Queue journal
  • Ledger journal
  • Network acknowledgements
  • Statements
Recovery
  • Rebuild the authoritative queue
  • Mark completed work
  • Replay only proven missing items
  • Validate balances before full reopen

Design decisions

What is the unit of recovery?

  • Payment-safe checkpoint — Requires cross-system queue, ledger, network, and settlement evidence before replay.
  • Application availability — May restore a service quickly while leaving value state inconsistent.

Set recovery objectives for correct payment state and reconciled value, not process uptime alone.

How much payment data belongs in telemetry?

  • Minimised identifiers and outcomes — Supports correlation while reducing exposure and log-handling scope.
  • Full payloads — Makes some debugging easier but copies sensitive data into another high-risk store.

Log stable references, state, control outcomes, versions, and timings; retrieve protected payloads only through authorised case access.

Sources and disclosed synthesis