Skip to content

BRD.md

Latest commit

 

History

History
74 lines (64 loc) · 3.63 KB

BRD.md

File metadata and controls

74 lines (64 loc) · 3.63 KB
Raw

Business Requirements Document (BRD): FinTech Modernization Platform

Field Value
Document Business Requirements Document
Product FinTech Modernization Platform (ledger + settlement)
Version 1.0
Status Baselined
Owner Platform Architecture

1. Purpose

Define the business requirements for modernizing a legacy payments and settlement system of record into a cloud-native, event-driven platform without a high-risk big-bang cutover.

2. Background and problem statement

The incumbent platform is a monolithic/mainframe system of record that is costly to run, slow to change, and a single point of operational risk. The business needs faster delivery of new payment capabilities, lower run cost, and continuous regulatory auditability, while the existing system stays online throughout the transition.

3. Business objectives

ID Objective Measure of success
OBJ-1 Reduce delivery lead time for payment features +50% deployment frequency
OBJ-2 Lower platform run cost See COST-SAVINGS.md
OBJ-3 Eliminate cutover risk Reversible migration at every step
OBJ-4 Guarantee auditability 100% of postings reconstructable from the event log
OBJ-5 Maintain availability during migration No degradation of the 99.99% SLO

4. Scope

In scope

  • Event-sourced, CQRS ledger (post/reverse payment, balance read model).
  • Orchestrated settlement workflow with compensation (SAGA).
  • Strangler-fig routing facade and Anti-Corruption Layer.
  • Change-data-capture from the legacy system via transactional outbox.
  • Progressive (canary) delivery with automated rollback.

Out of scope

  • Replacement of upstream channels/UI.
  • Regulatory reporting product (consumes events downstream).
  • Fraud scoring (separate platform; consumes the event stream).

5. Stakeholders

Stakeholder Interest
Payments product New capabilities, time-to-market
Finance / Treasury Correctness, reconciliation, audit
Risk & Compliance Auditability, controls, reversibility
Platform engineering Operability, cost, reliability
Internal audit / regulators Reconstructable history

6. Business requirements

ID Requirement Priority
BR-1 The system shall record every money movement as an immutable, ordered event. Must
BR-2 The system shall expose current balances for query with read-your-writes consistency. Must
BR-3 A retried payment with the same payment identifier shall never post twice (idempotency). Must
BR-4 A settlement that fails downstream shall be automatically compensated (reversed). Must
BR-5 Legacy state shall be consumed without a shared database and without leaking legacy schema. Must
BR-6 Traffic shall be shiftable between legacy and new services by percentage, and reversible. Must
BR-7 Releases shall be progressively rolled out and auto-rolled-back on SLO breach. Should
BR-8 The read model shall be rebuildable on demand from the event log. Should

7. Assumptions and constraints

  • The legacy system can host a transactional outbox table (or expose its DB log for CDC).
  • Event payloads are versioned; consumers tolerate at-least-once delivery (idempotent).
  • Compensations are business reversals (new entries), never destructive deletes.

8. Risks

Risk Mitigation
Reconciliation gaps during coexistence Parallel-run + automated reconciliation before weight increases
Event schema drift Versioned events in common-events; backward-compatible evolution
Hot-account partition skew Sub-keying strategy for projections (see SYSTEM-DESIGN.md)