Skip to main content

Bank8:Risk — Business Requirements & Functionality

Audience: product owners, business analysts, and anyone evaluating what Bank8:Risk does for the business. For architecture read README.md; for wire-level detail read DESIGN.md.

1. Business Purpose​

  • Risk known at any moment, not just at filing time — capital adequacy, liquidity coverage, credit loss, and limit headroom are measured continuously from the bank's own posting and payment events.
  • Breaches surface instantly — crossing a limit is a domain event that alerts Compliance and feeds Reporting, rather than a number found later in a spreadsheet.
  • Portable thresholds — Basel/CRR3 output floors, OSFI CAR/LAR, US Basel III are jurisdiction registry data, not hardcoded.

2. Business Scope (What the Service Provides)​

#Capability areaWhat the business gets
1Exposure measurementCounterparty/currency/asset-class positions updated incrementally
2Capital measurementBasel capital components and ratios (CET1, Tier 1, total)
3Liquidity measurementLCR/NSFR buffers and ratios
4Credit riskIFRS 9 expected-credit-loss staging (12-month vs lifetime)
5Limit monitoringThresholds with breach events
6Stress testingScenario runs with assumptions and outcomes
7Domain eventsbank8:risk:* family (breach, stress completion)
8Health & opsHealth endpoint, metrics, audit journal

What the service does NOT own (business boundary):

Out of scopeOwned by
Money movement / balancesBank8:Ledger
Payment stateBank8:Payments
FilingBank8:Reporting
Tenant-authored hook executionSentin8:Func (Risk consumes results)
Metric aggregationSentin8:Stat

3. Business Capabilities​

CapabilityBusiness rule
ExposureEvery posting updates the relevant exposure; re-delivery never double-counts.
CapitalCapital ratios reflect current exposures; floors are jurisdiction data.
LiquidityLCR/NSFR buffers are measured from current asset/liability positions.
Credit lossECL staging reflects credit events in near-real time.
LimitsA breach is emitted exactly once per threshold crossing.

4. Business Events (Outbound)​

EventFires when
bank8:risk:limit:breachedA measured value crosses a configured limit
bank8:risk:stress:completedA stress scenario run finishes

5. Business Rules & Invariants​

  1. Exposure updates are idempotent per event.
  2. A breach is emitted at most once per (limit, direction) transition.
  3. Risk never writes another service's tables.

6. Target-User Roles & Use Cases​

RoleUse case
Risk officerReviews exposures, limits, ECL; runs stress scenarios
Compliance officerConsumes breach alerts
RegulatorReceives capital/liquidity inputs via Reporting

7. KPIs / Success Criteria​

  • Breach detection latency ≤ seconds from the triggering posting.
  • Zero double-counted exposures.

8. Dependencies & Reliance on Other Services​

  • Bank8:Ledger, Bank8:Payments (events), Sentin8:Bus, Sentin8:Func, Bank8:Reporting (downstream consumer).

9. Acceptance Criteria​

  1. A posting event updates the matching exposure exactly once.
  2. A limit breach emits an event consumed by Compliance and Reporting.
  3. Jurisdiction thresholds are registry data.

10. Open Business Questions​

  • Cross-currency netting conventions.
  • Stress-scenario definition language.

Design attribution: bank8:risk and its underlying concepts were designed by Hamid Jahanzad Hamid@Jahanzad.com.