Product
Governed analytics for Bank of Maharashtra
Bank profile
बँक ऑफ महाराष्ट्र — public institutional context, not query output
Public contextFigures Bank of Maharashtra publishes itself, quoted here — this build did not compute them. Bank-level totals it returns match these published figures; the splits beneath each total are sample data.
The governed catalog is modelled on the same published position as on 31 March 2026, so a bank-level total the dashboard returns — deposits, gross advances, the GNPA and CASA ratios, the network counts — is the bank's own published figure and should reconcile against your MIS.
What is sample data is the split beneath each total: the zone, product and scheme breakdowns are illustrative, and are sized so they sum exactly to the published parent.
Nothing here is a live read of a Bank of Maharashtra system; this build runs on sample data, and the Connection panel below states whether a governed API is attached.
Governed sources
BoM's own systems of record, read through the governed metric catalog
- Payments Switch (UPI / IMPS / NEFT / RTGS) — ODS (India-resident)Read path: read-replica / ODS, under query governors · 25k records in the governed surfaceLast refresh —
- Core Banking (Finacle) — read replicaRead path: read-replica / ODS, under query governors · 13k records in the governed surfaceLast refresh —
- ATM Electronic Journal — ODS (India-resident)Read path: read-replica / ODS, under query governors · 9.4k records in the governed surfaceLast refresh —
- Loan Management (Finacle LAA) — read replicaRead path: read-replica / ODS, under query governors · 7.9k records in the governed surfaceLast refresh —
- CRM — ODSRead path: read-replica / ODS, under query governors · 6.1k records in the governed surfaceLast refresh —
- Digital Channels — ODSRead path: read-replica / ODS, under query governors · 5.3k records in the governed surfaceLast refresh —
- Card Management System — ODS (India-resident)Read path: read-replica / ODS, under query governors · 4.4k records in the governed surfaceLast refresh —
- ATM Switch — ODSRead path: read-replica / ODS, under query governors · 3.5k records in the governed surfaceLast refresh —
- KYC / CKYC Register — ODSRead path: read-replica / ODS, under query governors · 2.9k records in the governed surfaceLast refresh —
- Branch MIS — nightly snapshotRead path: read-replica / ODS, under query governors · 2.1k records in the governed surfaceLast refresh —
- HRMS & Facilities — ODSRead path: read-replica / ODS, under query governors · 1.2k records in the governed surfaceLast refresh —
Every source is read from a read-replica, ODS or nightly snapshot under query governors — never live OLTP (§6). Record counts and refresh times shown here are sample figures.
The estate behind these entries is the bank's own: Core Banking and Loan Management on Finacle, the CRM stack that carries branch and call-centre service requests and grievances, the ATM switch and its Electronic Journal, the payments switch behind Maha UPI / IMPS / NEFT / RTGS, the card management system, the digital channels — MahaConnect, MahaSecure and the Zen Lyfe app — the PMJDY / financial-inclusion portal that carries Jan Dhan, DBT and social-security scheme reporting, the CKYC register, and HRMS.
Reporting load is isolated on the replica / ODS under per-connection resource caps, so a report can never degrade BoM's core operational systems (§6, R8). The India-resident annotation on the payments switch, the ATM Electronic Journal and the card system records RBI's payment-data localisation direction against those stores.
There is no field-level hold-back: monetary columns, ATM Electronic-Journal transaction rows, and KYC operational and document-status data are all reachable through the governed catalog. The one exception is that Aadhaar / UID numbers are rendered with the last four digits only and are never returned in full.
Regulatory obligations in scope
360 Labs' working position — subject to BoM legal and the BoM DPO
The governed catalog covers the bank's payment, financial and personal data, so this build owns the obligations that attach to processing it — accepted and controlled on the governed path, not avoided by keeping the data out.
One carve-out. Aadhaar / UID numbers render with the last four digits only and are never returned in full. Every other KYC attribute is answerable.
There is no scope boundary excluding these obligations any more, and no argument resting on one. The control is on the governed path: one sanctioned definition per figure, no ad-hoc SQL, emitted SQL and definition version on every answer, and an append-only audit record.
- The Payment and Settlement Systems Act, 2007.
- RBI's payment-data localisation direction — payment system data stored in India.
- RBI customer-liability rules on unauthorised transactions, where relevant.
- DPDP obligations, across a materially larger and more sensitive personal-data surface.
- RBI Outsourcing of IT Services MD 2023, RBI IT Governance MD 2023, and the CERT-In directions — already in scope, and unchanged.
Why Aadhaar is the exception. The Aadhaar Act attaches criminal liability to UID handling, which is a materially different risk class from the disclosure and localisation regimes that govern payment data. Everything else about KYC — operational counts, processing durations, document status, verification state — is in scope and answerable. This is a masking rule at the catalog and presentation level, not a scope phase.
Every regulatory characterisation above is 360 Labs' working position and is subject to confirmation by BoM legal and the BoM DPO. None of it is settled fact. Widening the data scope makes that qualification more important, not less.
Connection
How this dashboard reaches the governed brain
Demo stubA config value, not an authenticated user. Nothing here enforces per-user scoping, so this build must not be pointed at real BoM data until per-user identity is in place.
Production user auth is SSO/OIDC against BoM Active Directory, with the principal derived from the authenticated session token and never accepted as a free-form field, plus mTLS for service-to-service calls. None of that is implemented in this build, and the principal here is not §8-conformant.
With the catalog spanning financial, payment and personal data, that absence is a materially larger gap than it was under a non-financial scope. There is no per-user boundary between any reader of this dashboard and a rupee balance, an ATM Electronic-Journal row or a KYC record; FR-10's policy denial has no authenticated caller to deny.
Going live
From sample data to the Core Banking (Finacle) read-replica the governed API reads
- 1. Start
ent-apion this host (or reachable over the tailnet), pointed at the read-replica / ODS for each source, never at a live OLTP system of record. - 2. In the dashboard's
.env, setENT_MOCK=0and pointENT_API_BASEat it. - 3.
ENT_API_TOKENis for non-PII health checks in development only. It is not the go-live auth path. - 4. Go-live auth is SSO/OIDC against BoM Active Directory, with mTLS between services (§8). It is not implemented in this build and is a prerequisite for querying real BoM data.
§8 explicitly rejects a single shared static bearer as the auth model for a system querying personal, financial and payment data: any token-holder could assert any principal, which would defeat FR-1, FR-10 and FR-11.
The token stays server-side; it is read only by the dashboard's /api/* proxy routes and never reaches the browser. It authenticates this dashboard to the API — it does not identify a user, and it is not a substitute for the per-user identity §8 requires, where the principal is derived from the authenticated session token.