Learn

Architecture & extensions

Cadence is built around a few clean seams: a third-party/account-servicer boundary, a product-parameterised decision core, swappable provider adapters, and per-session persistence. Each seam is a place the system can grow.

The boundary

Third-party provider and account servicer

The open-banking split is modelled explicitly so the wire format never leaks into the decisioning code.

Cadence, the TPP console

Cadence is the third-party provider and the loan-officer console. It holds consent, runs categorisation and affordability, and owns the decision and audit trail. Nothing about a particular account servicer is hard-wired into its domain logic.

Demo Bank, the mock ASPSP

Demo Bank is a mock account-servicing institution exposing account-information endpoints in the Berlin Group NextGenPSD2 shape. Cadence's account-information adapter maps that wire format onto its internal transaction model, so the rest of the system sees one stable domain type.

The core

A product-parameterised engine

One rule core, different parameter sets per product. The consumer instalment loan is active today; the mortgage parameter set is already defined to prove the seam.

Consumer loan, active

The live product runs the full Haushaltsrechnung and rule set: affordability buffer, debt-to-income ceiling, stability and tenure minimums, and a rate-stress test, all expressed as named parameters on a single product config.

Demo APR: 7.9%
Max DTI: 40%

Mortgage, the next module

The mortgage seam reuses the same core with a heavier parameter set and a few product-specific inputs. It is defined but inactive in the demo. The seam is the point of interest rather than the screen.

Property value: Purchase price input
Maximum LTV: 90%
Minimum equity: 10%
Term: 120–360 months
Stress-rate buffer: +3.0 pp

The seams

Provider abstractions & persistence

Swappable providers

Account-information access and the language model are both reached through provider interfaces. The mock account servicer can be replaced with a live one, and the categorisation model can be swapped, without touching the decision core. Each provider is an adapter rather than a dependency baked into the rules.

Per-session persistence

State is persisted to a serverless Postgres store through a typed query layer, keyed by session. Every session is isolated by its identifier, so one applicant's data, decisions and audit log never cross into another's.

The horizon

Open finance as the natural extension

Beyond payment accounts

The same architecture extends naturally from payment-account data toward broader open-finance access covering savings, investments, pensions and insurance brought under comparable consent-based sharing. A wider evidence base would sharpen both categorisation and affordability while the boundary, the decision core and the audit trail stay as they are.

This describes how the system would grow. The demo does not run on any of it. The demo stays within account-information access, and the forward path is additive, plugging new providers into seams that already exist.

Layer 4

The audit