A payments institution must satisfy prudential and conduct regulation. Which architectural properties do these requirements actually demand?

The properties that are actually demanded

• An immutable, complete, attributable audit trail with absence detectable — sequence numbers or chaining, since a log that can silently lose entries provides no assurance and the missing entry is the interesting one. Attributable to a person rather than a service account, since "the batch job did it" is not an answer.
• Reconstruction of any past state, because the regulator's question is usually about the past. That requires point-in-time capability rather than only current state.
• Segregation of duties enforced structurally, so no single credential — including a database administrator or a root cloud account — can both initiate and approve a value transfer. The test is concrete and the answer is frequently uncomfortable.
• Client money segregation reflected in the data model, not merely in a ledger convention, since the distinction is a legal one with a physical consequence.
• Continuity and recovery objectives per business capability, evidenced by rehearsal rather than by a document.
• Reporting reproducibility, so a submitted figure can be regenerated and traced to its inputs.

What the requirements do not demand

A specific technology, a particular architecture style, or manual approval on every change. The requirement is that changes are authorised, tested, traceable and reversible with evidence — and automated gates satisfy all four better than manual approval, producing a logged, timestamped, attributable record as a by-product.

Presenting that argument with the delivery data is what allows a regulated institution to ship continuously, and it is an argument worth making rather than assuming the constraint.

The properties that make incidents manageable

• A place to put "unknown", since a timeout on a payment means you do not know — and a system with only success and failure will guess, which is how duplicates are born.
• Reconciliation as a designed capability, since it is the control that finds what the pipeline does not know it missed.
• Regulatory notification timing understood, since the clock starts at detection and it is frequently the most time-critical item in an incident while being the one engineering considers last.

The framing worth holding

The regulation constrains outcomes, not mechanisms. An architecture that satisfies the outcomes with automated controls is both more defensible and faster than one that satisfies them with process — and the second is what organisations default to because it is what the auditor last asked about.