PLATFORM

One core banking platform. Every brand you launch.

FinLabCore is a ready-to-use, modular digital banking and payments platform: accounts, international and local payments, FX, cards and crypto on one core, with a real double-entry ledger underneath and a complete back office beside it. Each brand you launch is a tenant, not a fork.

✓ Live in production, powering Montowire.   See the Ledger →

How a modular banking platform fits together

Five layers, one product. “Modular” here is not a slogan, capabilities are enabled per tenant, so what a brand sells is configuration, not custom development.

  1. Channels. A white-label web application, native iOS and Android apps, the back-office console, plus API access for partners, with per-partner credentials and webhooks.
  2. Financial capabilities. Accounts and payments, FX and crypto, cards, the products your clients see.
  3. Commercial, compliance and operations. The tariff engine and agent channel, KYC/KYB, transaction monitoring and four-eyes controls, ticketing and management reporting.
  4. The accounting core. A double-entry ledger that every capability above books into, balances are derived from entries, never stored as editable rows.
  5. Integration and tenant infrastructure. Provider connectors, event delivery, tenant isolation, automated deployment, configuration-as-code and operational monitoring.

Every layer ships with the platform. There is no “and then you build the rest” footnote.

A multi-tenant banking platform: one core, many isolated brands

Each brand or partner operates as an isolated organization, its own clients, its own data, its own enabled capability set, its own theming across web, mobile and back office. Onboarding a new brand does not require a separate build, and no tenant ever runs on a diverged codebase.

Capabilities are sold, not hardcoded: fiat, cards and crypto are switched on per tenant, with controlled rollout and instant switch-off. That means packaging and pricing can differ by market or brand while the core stays one product, the economics behind a white-label launch.

Core banking software that owns its books

Most platforms in this category store balances as rows in an application database and mirror a provider’s numbers. FinLabCore is built the other way up: a classical chart of accounts, atomic write-once entries, and every balance derived from them. Positions carry dual valuation, account currency and reporting currency, revalued daily as FX moves. Client funds are booked as liabilities, separated from safeguarding accounts and reconciled against them.

The consequence evaluators care about: the client statement and the general ledger agree by definition. Financial statements, trial balance and safeguarding proofs come from the same engine that runs the product. How the Ledger works →

Rails, issuers and venues as configuration

Payment providers, card issuers and exchange venues sit behind an integration layer. Per-rail behaviour, automatic processing or manual routing to back-office approval, is configuration. Several card providers can run side by side, each with its own currencies, account structures and per-tenant settings, so a brand launches with the provider that fits its market and switches without touching the product.

New rails and geographies are commercial decisions with a defined onboarding path, see Integrations and Providers.

The layer works in both directions. The same infrastructure that consumes external providers can expose the platform’s rails to external businesses: API access with per-partner credentials, token and key management, IP restriction, and inbound and outbound webhooks are already in place. That same infrastructure powers the merchant-facing payment gateway.

White-label web and mobile banking apps, included

Clients reach the platform through two channels, both live: a web application and native iOS and Android apps, themable per brand, covering the full day-to-day journey: balances, payment creation and signing, FX, cards, statements and support.

Payment authorisation works on mobile, so signatories approve on the move instead of being tied to a desk. Your brand ships with real apps on day one, not a roadmap item.

The back office is part of the platform

Every client-facing capability has an operational counterpart: onboarding review and approval, payment lifecycle management and investigation, manual bookings and period-end routines, price lists and client plans, integrated ticketing, operational queues and a management reporting suite, all role-based, all attributable.

A new tenant inherits this complete operating capability on day one, which is why headcount scales with business volume rather than transaction count. Inside the Back Office →

Security and operations posture

  • Segregation of duties. Client and back-office access live in separate domains; roles gate what each person sees and does, and every action is attributable.
  • Four-eyes on money movement. Client-side signatory mandates plus back-office approval; pricing and money-routing changes are separately audited.
  • Screened before it leaves. Every payment passes compliance screening with hold, rejection and action-required outcomes; per-client limits respond to risk rating, PEP and US-person status; country-level controls are maintained centrally, Onboarding and Compliance.
  • Auditable end to end. Full history for payments, signatures, ledger entries, provider exchanges and administrative actions.
  • Operated like software should be. Automated deployment, configuration-as-code, platform metrics, error tracking and alerting, Cloud and Operations.

Everything you would evaluate is running

One platform, in production, end to end: multi-currency accounts, SWIFT and SEPA, local and instant rails including Interac and ACH/EFT, on-platform transfers, spot FX, crypto accounts, transfers and conversion, crypto pricing through the tariff engine, cards with multi-provider setup, KYC/KYB, transaction monitoring, four-eyes and safeguarding, regulatory (FINTRAC) reporting data, the tariff engine and agent channel, the full back office and reporting suite, white-label web and native iOS and Android apps, automated deployment, configuration-as-code and monitoring, settled through integrated providers and the platform’s own correspondent relationships with direct SWIFT connectivity.

Where the platform goes next, FX margin trading, and the on-request catalogue of deposits, lending and new rails, lives on the roadmap.

Core banking platform FAQ

What does “modular” mean in practice?
Capabilities, fiat accounts, specific rails, cards, crypto, are enabled per tenant from the back office, with controlled rollout and instant switch-off. Packaging differs by brand or market; the core stays one product.
Cloud deployment with automated provisioning, configuration-as-code and operational monitoring, details on Cloud and Operations. The specifics of your environment are scoped per engagement during the demo process.
A tenant is configuration, not a project fork: branding and theming, the enabled capability set, provider routing, tariffs and compliance rules. See it end to end in a demo, or read how it plays out for a white-label launch.
Behind the integration layer, as configuration. Multiple providers can run in parallel, per brand, per currency, per rail, and adding or switching one does not touch the product. Integrations →
FinLabCore is core banking and payments software, you operate under your own regulatory permissions, hold your own client relationships, and keep your own books. A BaaS relationship rents you someone else’s stack and balance visibility; here the ledger, pricing and operations are yours. Compare the routes on Launch a Bank.
Yes, the integration layer works outbound as well: API access with per-partner credentials, key management, IP restriction and webhooks is live, and the merchant-facing payment gateway runs on exactly that layer.

Walk through the platform live

Client apps, back office, ledger, running in production, not in slides. Bring your capability list; we will show you where each piece lives.