ADR-006: ERP at the periphery — statutory reporting only¶
| Status | Accepted |
| Date | 2026-04-10 |
| Deciders | CFO, CTO |
| Affects repos | bank-risk-platform |
Status¶
Accepted — 2026-03-23
Context¶
Many banks run core operational processes through their ERP. This creates tight coupling between the ERP's data model and the bank's operational systems, and makes the ERP a critical path dependency. The bank's ledger, P&L, and balance sheet are computed from Postgres and Snowflake — the ERP should consume these outputs, not drive them.
Decision¶
A tier-2 ERP (e.g. Xero, NetSuite) is used solely for statutory financial statements, tax compliance, and accounts payable/receivable. The ERP consumes aggregated financial data from Snowflake via a read-only data feed. The ERP does not write to any operational system. The bank's general ledger is Postgres — not the ERP.
Consequences¶
Positive - No ERP on the critical transaction path — outage does not affect banking operations - ERP can be replaced without affecting any operational system - Statutory reporting is derived from the same authoritative data used for regulatory reporting
Negative / trade-offs - Custom ERP integration feed must be built and maintained - Statutory accounts require reconciliation between ERP and Snowflake data
Constraints this creates for bank-risk-platform¶
- ERP feed is read-only from the bank's perspective — bank-risk-platform pushes aggregated data out
- Feed driven from Snowflake aggregated financial data — not from direct Postgres connections
- ERP must never be given write access to any bank operational system
Principles alignment¶
| Principle | Assessment | Notes |
|---|---|---|
| AP-001 KISS | ✓ | ERP at periphery means no ERP on critical path; simpler operational model |
| AP-006 Cost effective | ✓ | Tier-2 ERP (Xero/NetSuite) is cheap; no enterprise ERP licensing |
| AP-007 Evolution | ✓ | ERP can be swapped without touching any operational system |
Perspectives¶
| Perspective | Assessment | Notes |
|---|---|---|
| Strategy | ✓ | Avoids ERP vendor lock-in on core banking operations |
| Integration | ✓ | One-way feed from Snowflake; simple and auditable |
| Cost | ✓ | Tier-2 ERP pricing; no implementation consulting overhead |
| Regulatory | ✓ | Statutory accounts derived from same source as regulatory returns — consistency |
| Support & Maintenance | ✓ | Minimal integration surface; ERP is largely self-service |
See perspectives.md for how to use these evaluation lenses.
Relevant viewpoints¶
- System viewpoint — ERP as a consumer of Snowflake aggregated data; one-way data flow
- Information viewpoint — Which GL aggregations are published to the ERP feed
See viewpoints.md for guidance on producing these viewpoints.
Signoff record¶
| Date | Name | Role | Status |
|---|---|---|---|
| 2026-04-10 | Ross Millen | CTO | Approved |
| 2026-04-10 | Ross Millen | Head of Architecture | Approved |
| 2026-04-10 | Ross Millen | Head of Data | Approved |
Capabilities¶
| Capability | Description | Relationship |
|---|---|---|
| CAP-025 | Automated regulatory reporting pipeline | governed — ERP consumes Snowflake aggregates; not the source of truth for regulatory returns |
| CAP-126 | Statutory financial reporting (ERP feed) | enabled — automated one-way Snowflake to ERP feed for statutory accounts |
Related decisions¶
| ADR | Title | Relationship |
|---|---|---|
| ADR-002 | Snowflake as the analytics and risk compute platform | ERP receives a read-only aggregated feed from Snowflake |
All ADRs
Compiled 2026-05-22 from source/entities/adrs/ADR-006.yaml