Skip to main content
Requirements review v0.2 • 14 October 2026. All new Banking modules are proposed; no implementation or permission is approved by this map. A module is a business responsibility. An application is where a person uses it. An offering is the institution-specific bundle of permitted products, modules and channels. Start here explains those three layers with one bank and one NBFC example.

Module responsibilities and handoffs

Debit, prepaid and credit: the same card action, different money

The following are simplified fictional arithmetic examples with no fees, taxes, currency conversion, other holds or other transactions. They do not adopt actual limits or pricing. For all three, B17 supplies the card identity and B21 co-ordinates the network event. A failed/unknown authorisation does not justify a second debit. A matched reversal must resolve the original event under adopted rules.

Lending handoffs

The diagram shows responsibility handoffs. The execution sequence supports multiple B13 assessments requested by B12 before final accepted terms. Institution-approved state transitions and source ownership are required implementation inputs.

Module-by-module ownership directory

Organisation, customer and core records

Lending

Cards and ATM

Cross-module controls

Implementation and documentation status

Each module’s Current implementation and reuse section records legacy evidence. Required implementation inputs records the institution policies and contracts needed for implementation. The delivery gates define acceptance.

Reference and design ownership

M2P publicly groups origination, servicing, collateral and collections within its lending suite. That is a reference for explaining modular responsibilities, not an adopted architecture or provider contract. The ownership boundaries above are this project’s proposed design. M2P core lending suite and reference basis.