> ## Documentation Index
> Fetch the complete documentation index at: https://banking.nextedge.consulting/llms.txt
> Use this file to discover all available pages before exploring further.

# Decision register

> Required ownership, policy, interface and release inputs for planned Banking functionality.

**All decisions below are open for the new Banking project unless explicitly recorded as confirmed.** Describing a candidate module or fictional example does not approve it.

## Confirmed project scope

New project name Banking; Super Admin, Banking Operations, Customer Web, mobile-facing APIs and ATM application; bank/NBFC and debit/prepaid/credit-card coverage; configurable offerings; Mintlify-first review with module flows/examples; confirmation before implementation.

## Decision 1: core ownership

**Required selection: Pending.** The authoritative account, deposit/loan subledger and general-ledger ownership model must be recorded as owned core, external-core operations or an explicitly defined hybrid.

| Option | Result | Main dependency |
| - | - | - |
| Owned core | Banking implements financial books, product economics, business-date/EOD and controlled correction | Full accounting/policy ownership, migration, reconciliation, audit and recovery acceptance |
| External-core operations platform | Banking manages approved operating/channel workflows; existing core confirms books and financial effects | Complete read/quote/instruction/status/finality contracts and bank-owned connector |
| Explicit hybrid | Name exactly which product books are owned and which are external | Cross-book settlement, source of truth, reconciliation and failure ownership for every boundary |

The selected core boundary determines financial-book ownership, implementation scope, interface contracts and release evidence for the first institution.

## Sequenced remaining decisions

The following inputs are sequenced after core ownership and require accountable-owner confirmation.

| ID | Required input | Blocks |
| - | - | - |
| D02 | First institution category and permitted offering: bank, lending NBFC, card issuer or prepaid issuer. | Legal capability and launch product bundle |
| D03 | First-release product, customer segment and end-to-end acceptance journey. | Execution packet and acceptance sample |
| D04 | Accountable issuer/lender/deposit holder and policy, finance, security and UAT owners. | Accountable permissions and commissioning |
| D05 | Contracted core, provider, processor and network interfaces; connector implementation owners. | Real instructions, statuses and certification |
| D06 | Product economics, posting rules, business calendars, statements and closure semantics. | Exact calculations and financial jobs |
| D07 | Action-specific maker, checker and override duties; amount and branch boundaries. | Approval and staff access |
| D08 | First-release physical/virtual debit, prepaid and credit variants and programme responsibilities. | Card engines and issuer configurations |
| D09 | ATM terminal-client/fleet-console scope, vendor, switch and permitted services. | Hardware/security/cash integration |
| D10 | Mobile client, session, device, proof and recovery contracts. | Mobile API security and commissioning |
| D11 | New-project scope and policies for held complaints, private notes and reassignment workflows. | Their states, visibility and servicing policy |
| D12 | Explicit commissioning scope for treasury, UPI, foreign exchange, acquiring and specialised lending. | Scope expansions; none inferred from M2P |
| D13 | Mandatory reports, notices, retention, filing and reconciliation completeness rules. | Operating/regulatory acceptance |
| D14 | Deployment isolation, residency, capacity/latency and recovery targets. | Infrastructure, performance and DR acceptance |
| D15 | Separate implementation-repository destination. Banking documentation repository and hosted Mintlify destination are confirmed. | Implementation setup ownership; documentation destination complete |

## Decision record format

For each answer record authorised owner, date, selected option, rationale, scope, impacted modules, exact policy/contract/version, synthetic examples and remaining dependencies. Keep implementation authorisation separate from production release.

Legacy permissions/holds remain facts about the old project. They are not automatically new financial grants and need not be re-asked to preserve their current behaviour. M01 acceptance is separately pending; reviewing Banking does not start M02 or accept the legacy release.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.