FinTech Payments & Compliance on AWS (2026): Ledger, Fraud, and PCI Boundary Reference Architecture

AWS Payment Cryptography achieved Cartes Bancaires approval in February 2026, adding to PCI PIN, P2PE, 3DS, and DSS-aligned controls on PCI PTS HSM V3 hardware (What’s New). Amazon Verified Permissions runs Cedar 4.7 for fine-grained authorization decoupled from payment APIs (AVP docs).

This post is the FinTech payments reference architecture, covering the PCI boundary, ledger, crypto, and fraud lanes. General principles are in general fintech patterns, the control checklist is in the PCI control checklist, and operational resilience is in DORA operational resilience.

Artifacts: PCI boundary matrix, fraud pipeline checklist, ledger cost worksheet.

Four lanes from authorize to settle

Opinionated take: Isolate PCI in its own account before optimizing fraud ML. Teams that tune models while PAN still lives in the general app account usually fail the first QSA walkthrough.

Reference architecture

Terminals / wallets ──► API GW ──► Payment Cryptography (P2PE decrypt, PIN translate)
                              │
                              ├──► Step Functions (authorize workflow)
                              │         │
                              │         ├──► Aurora ledger (pgaudit)
                              │         └──► EventBridge (auth event)
                              │                   │
                              │                   └──► Pipe ──► Fraud Lambda ──► allow|review|decline
                              │
Merchant portal ──► Verified Permissions (Cedar) ──► ops APIs (non-PCI account)

Lane 1: PCI account boundary

Walk pci-boundary-decision-matrix.md:

• Payments OU with SCP deny on public S3 and unapproved regions
• No shared CMK between PCI and marketing analytics
• CloudTrail organization trail + immutable S3 log bucket

Lane 2: Payment Cryptography

Per Payment Cryptography features:

• Elastic crypto vs dedicated rack HSMs
• TR-31 key import/export for partner banks
• CloudTrail on control plane for PCI evidence

Use P2PE decrypt at the edge of the PCI account; never pass clear PAN to the general app tier.

Lane 3: Ledger (post-QLDB)

Amazon QLDB ended July 31, 2025. For new platforms:

-- Aurora PostgreSQL 15+ with pgaudit — append-only ledger table pattern
-- Assumed: pgaudit extension enabled, application role INSERT-only on ledger schema
CREATE TABLE ledger.postings (
  posting_id UUID PRIMARY KEY,
  account_id UUID NOT NULL,
  amount_cents BIGINT NOT NULL,
  currency CHAR(3) NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Model monthly cost in ledger-cost-worksheet.csv. Reprice Payment Cryptography ops in your region.

Lane 4: Fraud pipe

Follow fraud-pipeline-checklist.md:

• Custom EventBridge bus per environment
• EventBridge Pipes with DLQ. Do not invoke the fraud Lambda directly from API Gateway
• Idempotency table on network_transaction_id

When NOT to escalate

What to Do This Week

1. Run pci-boundary-decision-matrix.md with security + payments lead.
2. Complete fraud-pipeline-checklist.md and block prod authorize until idempotency row checked.
3. Reprice ledger-cost-worksheet.csv vs colo HSM lease.
4. Pilot Payment Cryptography P2PE sample from AWS samples repo.
5. Stand up Verified Permissions policy store for merchant ops, with UUID principals only.

What This Post Doesn’t Cover

• Open banking PSD2 consent APIs: regional regulatory overlays
• Crypto-native payments: different ledger and compliance model
• Full PCI SAQ evidence pack: use PCI architecture guide
• Cross-border FX settlement: treasury and nostro accounts

We have not load-tested Payment Cryptography above 25M crypto ops/month in a single region. Run a 1M-op soak test before peak holiday traffic.

Related: Fintech industry hub · Cloud security · Cloud compliance

Frequently asked questions