Solutions · Banks and subsidiaries
A savings-finance line of business without touching core banking
Do not squeeze savings finance into your existing core. Ordo is a white-label side core running next to the bank on its own event ledger and rule sets — inside the bank or as a subsidiary.
Known challenges
The known challenges of the new line
- Risk of touching core bankingModelling savings finance inside the existing core: high-risk changes, long approval chains.
- Different product, different ledgerSavings finance is not a deposit product; pool, draw and allocation logic does not fit a banking core schema.
- Time to launch a subsidiaryFrom licence application to go-live: system selection, customisation and integration can take years, not months.
- Consolidated reportingMerging data from two systems for group-level accounting consolidation and regulatory reporting.
- Brand and experience consistencyKeeping the bank’s digital experience standard in the new line of business — without building a separate UI ecosystem.
Scenario
Launching a subsidiary, as the group CIO sees it
Seven steps from licence application to the first contract: provisioning, identity federation, brand, rule sets, regulatory prerequisites, shadow run and the flow into the general ledger.
Group CIO · subsidiary launch team step 01 of 07
Provision the tenant
The control plane registers and provisions the subsidiary’s tenant: its own event ledger, product catalogue and task inbox. Core banking is not touched in any way; the side core lives on its own ledger.
Bank realities
Designed around bank realities
Every requirement maps to a clear subset of the platform modules.
| Requirement | Modules | How it is met |
|---|---|---|
| A separate, event-sourced side core | event-store · domain · rule-engine | Savings finance runs on its own ledger with its own rule sets; core banking remains untouched. |
| Sign-in with the existing identity stack | Keycloak · OIDC · realm roles | The bank’s directory is federated through Keycloak; permission codes are realm roles, so no second user directory is needed. |
| Flow into group accounting | accounting · exports · outbox | Entries derived from the event ledger and the event stream flow into the general ledger, mapped to the bank’s chart of accounts. |
| White-label customer experience | branding · customer-web · mobile | Portal and mobile surfaces are dressed in the bank’s or subsidiary’s brand; the experience standard is preserved. |
| Fast subsidiary launch | control plane · provisioning | Product definitions, role matrix and process packages come prepared; the launch project is configuration, not customisation. |
| Group audit standards | audit · four-eyes · auditor | Internal audit and inspection reach the evidence sets directly through a read-only auditor profile. |
Integration
Integration with the bank ecosystem
The bank’s existing systems connect to the platform through the event stream, exports and identity federation.
- Core bankingCustomer master data, account activity streams and reconciliation — through the event stream and export endpoints, built by the institution
- Identity providerOIDC / SAML federation; the existing staff directory and role model mapped in Keycloak
- General ledgerChart-of-accounts mapping, journal transfer, consolidation reports
- Data warehouse and BItfs.events stream subscriptions and ClickHouse reporting views feeding the data warehouse
- Regulatory reportingReport preparation and submission flow; BDDK and MASAK transmission lines through the institution’s own integration
- Open APIAPI surfaces embeddable into the bank’s existing mobile and internet banking
Subsidiary, or a line of business inside the bank?
In a half-day discovery we map the architecture and operating model of both scenarios together.