When the architecture has to satisfy a financial regulator
In regulated finance the design and the evidence that the design was governed are two deliverables, and the second one is the one that fails inspection.
The situation
The system is being designed or reviewed under regulatory obligations that specify recovery objectives, data protection and demonstrable control. The architecture work itself is familiar; the burden is proving it happened properly.
Recovery objectives are the sharpest constraint, because a recovery point objective of zero is not a stretch target — it rules out entire designs, and the ruling out should happen at the whiteboard rather than in a resilience audit.
The second burden is that every significant decision needs an approver and a date. Assembled afterwards, that record reads exactly like what it is.
You are here if
- Recovery objectives are stated in a policy but were never checked against a design.
- An examiner has asked who approved a design and the answer required archaeology.
- Encryption and public exposure are assumed rather than verified per component.
- Design reviews happen but leave no durable record.
How the work gets done
Put the regulatory objectives in the model as numbers
The banking pack sets the tightest targets of any pack, including a recovery point objective of zero seconds. Those numbers below are the ones the design is then evaluated against, rather than sitting in a policy document nobody evaluates anything against.
A recovery point objective of zero has architectural consequences that a diagram will not reveal on its own. Stating it in the model is what forces them into the open.
Simulate ▸ Industry PackSimulate ▸ Guided Setup Wizard
Check the policies that carry compliance weight
The pack highlights the policies on public database exposure, multi-availability-zone deployment for tier-one components, encryption at rest and the availability floor. Those four are evaluated against the model, per component, rather than asserted in a control narrative.
This is the part worth running early and often. A component that is exposed or unencrypted is cheap to fix at design time and expensive to explain later.
Simulate ▸ Policy & StandardsSimulate ▸ Principle ComplianceSimulate ▸ Rule Evaluation
Make the approval the artefact
Route the design through approval so that what was approved, by whom and against which version is recorded as it happens. In a regulated setting this is not administrative overhead — it is the deliverable that the examination actually inspects.
Diagram ▸ Approval workflowDiagram ▸ Version history
Record accepted risk explicitly
Every regulated architecture accepts risks it cannot design away. Recording them against the components they concern, with who accepted them, is the difference between a considered position and an oversight.
Arch ▸ Suggest risks from diagramArch ▸ Tech Debt ReportArch ▸ Repository
What the Banking & Financial Services pack sets
Regulated financial systems. Zero data loss, strict audit trails, and compliance-first architecture. Applying the pack switches the workload profile and sets these six targets on the model. It does not change the design and it does not enable any industry-specific check — the targets are what the design is then evaluated against.
| Workload profile | API-First Enterprise — Steady API traffic with strict latency SLAs and high auth overhead. |
|---|---|
| Availability target | 99.99% |
| Latency target (p95) | 150 ms |
| Throughput target | 2,000 requests/sec |
| Cost target | $100,000 / month |
| Recovery time objective | 1 minute |
| Recovery point objective | zero — no data loss permitted |
The policies this pack highlights
- No Public Database Exposure — Databases must not be directly accessible from the public internet without a proxy or API gateway.
- Multi-AZ Required for Tier-1 — Critical components must have replicas or be configured for multi-AZ deployment.
- Encryption Required — All data-at-rest components must have encryption enabled.
- Availability SLA ≥ 99.9% — System composite availability must meet or exceed the organisation baseline of 99.9%.
The risks it names for this industry
These are prompts to work through against your own design, not findings. The pack lists them; nothing evaluates them for you.
- Data loss on transaction records (RPO = 0 required)
- Regulatory breach from unencrypted data at rest
- Public DB exposure violating PCI-DSS
- RTO exceeding regulatory SLA for core banking
What is still yours to check
The simulation evaluates the architecture itself — single point of failure, deep synchronous dependency chain, shared database across services, connection pool saturation risk, no autoscaling configured and excessive retry configuration — against the targets above, and the policy checks run on every design. The concerns below are specific to banking & financial services and nothing in the product evaluates them. The pack names them so they stay on your list; the review is a human one.
- Encryption at rest and in transit across every store and every hop
- Audit trail completeness and immutability for transaction records
- Auth boundaries between customer-facing channels and core banking
- Data residency, retention and erasure handling under regulation
What you end up holding
- Recovery and availability objectives stated as model targets rather than policy prose.
- Per-component results for exposure, redundancy, encryption and the availability floor.
- An approval record naming version, approver and date, produced as the work happened.
- A register of accepted risks attached to the components they concern.
Not this, if
- You need attestation against a named standard. This produces architecture evidence; it is not a certification product and does not assert compliance on your behalf.
- The obligation is about running systems — access logs, patch levels, transaction monitoring. That is operational evidence and lives elsewhere.
- You are relying on the pack to check industry-specific security rules automatically. It sets targets and highlights policies; the security controls themselves still need a human review.