From a 223-item compliance register to a payment reference architecture

The problem

A platform that handles card-present payments sits inside card-brand rules, PCI standards, payments and tax law, state privacy laws, breach notification and accessibility duties.

Designing the product first and asking about compliance afterwards lets scope be decided by accident, and accidental scope is expensive to defend. This corpus inverts the order: a register of obligations is the requirements document the architecture must answer.

What was built

A pre-build design corpus for a card-present payment reference architecture: documents only, no code.

• A compliance register of 223 items across 15 sections, 92 of them marked as required at launch. Each item records its authority, legal or contractual force, whom it binds, when it applies, and a confidence flag. It distills into 17 architecture-driving constraints and a table of business-model tripwires: regimes dormant until the business changes shape.
• A core architecture document for the payment boundary and the systems around it, with a 15-row threat model, a 24-entry decision log and a 13-item residual-risk register.
• A crosswalk that goes through the register section by section, rates each compliance surface as covered, partial, missing or dormant, and names the subsystem that must own each gap. It found six domains with no architectural home; further draft architecture documents and a data-rights section were written to address them.

Register constraint	Structural answer in the design
Card data never enters platform software	Closed schemas, Luhn tripwires at every boundary, hostile-data tests as a release gate
Payment logic is a bounded module	One separately signed payment service with its own OS user and database: a bounded PCI Secure Software Standard validation target
The event log is legal evidence	Gapless hash chain with signed checkpoints in write-once storage
Retention collides with privacy	Per-category retention classes, legal-hold tooling required before the first prune, non-destructive redaction
Security controls are statutory	Hardware-sealed disk encryption, unique device credentials, a written security program to be mapped to NIST CSF and CIS Controls

Design decisions

Out of scope by structure. The register’s first constraint is that platform software never holds card data. The design makes that a property of topology and the data contract, pending a terminal verification spike: card data flows from an approved terminal to the processor, and the contract has no field a card number could travel in.

Structure does not remove every obligation. The platform still counts as a PCI third-party service provider, because its update pipeline and remote access can affect payment security, and must publish a written responsibility matrix for its customers. Other components touching payment-related data are named trust dependencies with compensating controls.

Honest merchant scope. Expected merchant outcomes are stated per terminal and processor pairing: SAQ P2PE only where a listed solution covers the exact pairing, SAQ C as the realistic default subject to the acquirer, SAQ D named as the fallback, and SAQ B-IP never claimed.

Segmentation and device identity. The deployment network is zoned and default-deny in both directions, with no inbound internet rule and port-level access control on the payment zone. Each device generates its key pair in its TPM and gets a short-lived certificate through an attested request.

Encryption and key-custody separation. Replicated data is encrypted client-side with keys the control plane cannot use alone. The replica, write-once anchors and escrowed recovery keys sit in a separate account with no standing cross-account read, so the design intent is that a control-plane compromise yields only ciphertext.

Signed artifacts and SBOM. Reproducible builds ship with an SBOM and provenance. Signing keys sit under an offline root, distribution uses signed metadata with rollback counters, and a copyleft-license scan fails the build.

Single-operator honesty. Where a control assumes two people, the design either adds an external second party before scaling or labels it a single-operator compensating control, never claiming separation-of-duties assurance it cannot deliver.

Evidence and limits

• The register came from a multi-agent research sweep with an independent adversarial verifier per domain. It states that it is not legal advice and calls for counsel and independent PCI review before launch.
• The core architecture was red-teamed: all 4 critical and all 14 high findings were applied as design changes, and cheaper medium findings were fixed inline. The remaining medium and low findings went to the residual-risk register, each with the reason it was deferred or accepted.
• The payment-boundary sections are conditional on a verification spike against real terminal hardware; until it closes, the corpus forbids any merchant-facing scope claim based on them.
• Integrity claims are scoped on purpose: the hash-chained log proves tamper-evidence of recorded events, not detection of a transaction that was never recorded.
• Nothing here has been built, tested or run against a live system.

Where it applies

• Authorization packages. A CMS ARS or FedRAMP package faces the same question: which components are inside the boundary, and why. A crosswalk, a decision log with rejected alternatives and a residual-risk register are the same kinds of artifact as a system security plan’s boundary narrative and the risk-acceptance and POA&M entries that go with it.
• Customer security questionnaires. A manufacturing supplier asked about signed updates, SBOMs and data custody is better served by an architecture that already records the answers than by drafting them per questionnaire.
• Fractional security leadership. For a mid-market organization, a register-first discipline separates obligations that shape the system now from dormant tripwires, and limits outward claims to what the design supports.

Independent work by Wade Blackwell. Each write-up is written from scratch for this site, without client, employer or personal data. Names, hostnames, addresses and configuration detail are left out on purpose.