# PCI boundary decision matrix (FinTech on AWS 2026)

Score each row 0–2 per column; sum ≥ 6 on a row → that boundary pattern is primary for your stage.

| Scenario | Dedicated PCI OU + account | Shared app account + network segmentation | Tokenization-only (no PAN in your estate) |
|----------|---------------------------|-------------------------------------------|-------------------------------------------|
| You store, process, or transmit cardholder data (CHD) | **2** — scope reduction via account isolation | 1 — possible with strict SG/NACL + dedicated subnets | 0 |
| P2PE from payment terminals (DUKPT) | **2** — AWS Payment Cryptography decrypt component | 1 | 0 |
| PIN translation across ISO formats | **2** — Payment Cryptography HSM-backed APIs | 0 — do not DIY in app tier | 0 |
| Partner bank requires per-tenant key separation | **2** — separate keys per partner via Payment Cryptography aliases | 1 | 1 if partner hosts crypto |
| MVP with Stripe/Adyen tokenization only | 0 | 1 | **2** |
| Need Cedar/ABAC for merchant vs ops roles | 1 | **2** — Verified Permissions policy store per app | 1 |

## Opinionated default

**Dedicated PCI-scoped AWS account** in a `Payments` OU when CHD or PIN blocks touch your code path. Use **AWS Payment Cryptography** (PCI PTS HSM V3, FIPS 140-2 Level 3) instead of self-managed payment HSMs when latency targets allow managed APIs.

## When NOT to expand PCI scope

- Card data never enters your VPC — stay on processor tokens
- "We'll encrypt PAN in our database" without a formal SAQ scope review — stop; legal + QSA first
- Sharing KMS keys between PCI and non-PCI workloads — split CMKs and accounts

## Ledger tier (post-QLDB)

Amazon QLDB was discontinued **July 31, 2025**. New ledgers: **Aurora PostgreSQL** with `pgaudit` + append-only table design, or **DynamoDB Streams → S3 Object Lock** for high-volume event logs.