Core model

Transactions and accounting are the core. Everything a product needs is configuration around it.

One solid core
One solid core, a configurable ringThe core of transactions and accounting in the centre; eight kinds of configuration around it.The coretransactions · accounting · value dating · day-endAccount typesconfigurationRate cardsconfigurationCalendarsconfigurationPosting rulesconfigurationWorkflow and four-eyesconfigurationPermissionsconfigurationStructures and entitiesconfigurationCapabilitiesconfiguration
The core has no idea what a mortgage is. A mortgage is configuration.

The core must not bend.

It posts every movement with a trading date and a value date, accrues, resets, revalues, closes the day and keeps the books in balance. Those books are a sub-ledger: they feed your general ledger through a journal export, XBRL GL among the formats, and reconcile back to it. The engine is not your general ledger and does not want to be. It has no idea what a mortgage is. A mortgage is an account type: positions, transaction types, schedules and rates, configured.

Accounts, structures, legal entities
AccountCurrency and scheduleRole in the structure
Loan GivenUSD 40,000,000, floating, quarterlythe asset
Funding TakenEUR 35,000,000, fixed, semi-annualfunds it
Swap Given and TakenUSD–EUR, notional matchedhedges it
Fee IncomeUSD, accruing dailyprices it

The four accounts form one structure. The structure belongs to a legal entity. The entity keeps its own books, so the deal's income, expense and FX result land in the right set of accounts without a single manual journal. Core platforms typically model the loan and lose the rest.

A modular monolith
Feature projects behind one contracts boundary, one deployableSix feature projects in a row, each with its own aggregates and tests, talking only through a contracts layer, deployed as one unit.Accountsown aggregates, own testsSchedulingown aggregates, own testsPaymentsown aggregates, own testsBooksown aggregates, own testsCollectionsown aggregates, own testsStructuresown aggregates, own testsContractsthe only way features talkOne deployableAPI, worker, day-end
Features talk through contracts. The build fails when one reaches into another.

Every feature is its own project with its own aggregates and its own tests.

Features never reference each other's implementation. They talk through contracts, and the build fails when someone tries otherwise. It deploys as one unit, which is what a bank's operations team can actually run. The modules are the boundaries a later split would follow, if one is ever needed.

What this means for you: the deal you cannot administer today is a structure, an account-type set and a posting group. Configuration, tested on sample data, then live.