Deposit and Savings Product Engine With Configurable Pricing
Launching a Savings Product Without Writing Code
Ask a bank how long it takes to launch a new savings product and the answer is usually measured in months. Ask what the work consists of and the picture becomes clearer: someone configures the product in the core, someone else maps it to the chart of accounts, a developer changes the statement template, another adds the notification, testing runs across four systems, and the launch date is set by whichever of those finishes last.
Almost none of that is inherent to deposit products. A deposit product engine that works turns most of it into parameters, and the difference between a bank that launches in a fortnight and one that launches in a quarter is mostly a question of how much of the definition lives in configuration and how thoroughly that configuration can be tested.
Why do launches take months?
Because configuration usually means development somewhere in the chain.
| Activity | Should be | Usually is |
|---|---|---|
| Product definition and terms | Configuration | Configuration, sometimes |
| Rate structure and tiers | Configuration | Configuration with code for unusual shapes |
| Eligibility rules | Configuration | Code |
| Accounting and ledger mapping | Configuration | Manual mapping plus code |
| Statement and document content | Template | Development |
| Notifications and alerts | Template | Development |
| Downstream reporting and risk feeds | Automatic from definition | Manual addition per product |
| Testing | Automated against the definition | Manual, across several systems |
The pattern is that a bank can configure the product and cannot configure everything the product touches. Fixing that means treating the product definition as the single source from which documents, notifications, accounting, and reporting are all derived, which is a wider change than a product engine project usually scopes.
How many separate systems need a change when you launch a savings product?
What must the engine model?
Nine elements, with versioning as the structural requirement underneath them.
| Element | Content |
|---|---|
| Product definition | Type, currency, term or notice structure, availability window |
| Eligibility | Customer segment, age, residency, existing holdings, channel |
| Rate structure | Tiers or bands, base rate linkage, promotional and bonus components |
| Balance rules | Minimums, maximums, funding windows, top-up permissions |
| Term and notice | Maturity handling, notice periods, early access penalties |
| Fees and charges | Types, triggers, waivers, caps |
| Limits | Withdrawal counts, amounts, frequency |
| Lifecycle rules | Maturity rollover, dormancy, closure, transfer |
| Accounting mapping | Ledger accounts, product codes, reporting classification |
Why is versioning the core requirement?
Because customers must keep the terms they were sold while new customers get current terms.
Every product needs immutable versions with effective dates, and every account needs to reference the version it was opened under. Without that, a rate change or a rule correction silently alters the terms of existing accounts, which is both a conduct failure and an operational one, since nobody can then explain what a given customer was entitled to. Build version identity into the data model from the start, because retrofitting it means reconstructing history from change logs that may not exist.
Why is grandfathering the hardest part?
Because a bank accumulates dozens of closed variants that must keep working correctly for decades.
Products close to new business and their accounts persist, sometimes for thirty years. That means the engine must continue to evaluate rules for variants nobody has thought about since before the current platform existed, and every migration or platform change must preserve their behaviour exactly. Inventory those variants explicitly, test them as first-class cases rather than as legacy exceptions, and resist the temptation to migrate customers to current products for convenience, since that is a customer terms change with its own obligations. The configurable product patterns are set out in this guide to building configurable products.
How should rates be structured?
As composable components with effective dates, not as a single rate field.
Real deposit pricing combines a base component, tier or band structure by balance, promotional or bonus rates with expiry conditions, loyalty or relationship adjustments, and sometimes linkage to an external reference rate. Model each as a component with its own effective dating and expiry, then compute the applicable rate for an account at a point in time by evaluating the components. That structure is what lets you introduce a bonus rate without redefining the product, and it makes the applicable rate at any historical moment reproducible, which matters for complaints and for accrual recalculation.
Why is a rate change a process rather than a field update?
Because it triggers notice, communication, effective dating, recalculation, and reporting.
Changing a savings rate downward typically requires advance notice to affected customers, and any change requires communications, an effective date applied consistently, accrual computed correctly across the boundary, statement and document updates, and downstream propagation to reporting and risk systems. Model the rate change as an orchestrated process with those steps as dependencies, not as an update to a value. Institutions that treat it as a field update discover the notice obligation was missed on a subset of customers, which is a remediation exercise.
What do conduct expectations imply for pricing?
That value and clarity are assessable, which makes product data a compliance artefact.
The FCA's Consumer Duty sets the Consumer Principle that firms must act to deliver good outcomes for retail customers, with outcomes covering products and services, price and value, consumer understanding, and consumer support. For a deposit engine that means the product data must support a value assessment, that rate structures complex enough to confuse are a design risk rather than a marketing feature, and that a customer left on a legacy product at a materially worse rate is a visible outcome. Build reporting that shows the distribution of customers across product versions and rates, since that is the view the conversation will be based on.
Can you report how many customers sit on closed product versions and what rate they receive?
How do you handle product change and customer migration?
Deliberately, with the distinction between permitted variation and terms change made explicit.
Some changes are permitted within existing terms, such as a rate move where the terms allow it with notice. Others amount to changing what the customer bought and require consent or a migration offer. The engine should make that distinction visible rather than leaving it to whoever configures the change: classify each change type, attach the required process, and prevent a change of the second kind being applied as though it were the first. Then handle maturity properly, since a maturing fixed-term deposit rolling into a materially different product without a clear choice is one of the more common sources of complaint in this product set.
How does this interact with interest calculation?
The engine defines terms and a separate calculation engine applies them.
Keep the two apart. The product engine answers what rate, fee, and rule apply to this account at this moment. The calculation engine answers what that produces in accrued interest and charges, with day count conventions, rounding, and compounding. Separating them means a rate structure change cannot break accrual logic and a calculation fix cannot alter product terms, and it lets both be tested independently. The calculation side is the subject of interest accrual and fee calculation engines.
How do you avoid a configuration language nobody can maintain?
By drawing the configuration boundary at a defined vocabulary and putting everything else in code.
The failure mode of product engines is a configuration surface that grows into a programming language: expressions, conditionals, embedded scripts, and eventually a system only two people understand with no tests and no version control. Draw the line explicitly. Configuration selects from a defined vocabulary of rule types with parameters, and any requirement needing new logic is a code change delivered through the normal pipeline. That keeps configuration reviewable by product people and keeps logic in a place engineers can test. The rules engine design considerations are covered in this guide to handling complex product rules.
Why is testing configuration the missing capability?
Because teams build the ability to define products and not the ability to verify a definition.
A product definition is executable specification, so it should be testable: given this definition, an account with this profile should receive this rate, accrue this amount, and be permitted these actions. Build a test harness where product definitions are exercised against scenario sets before release, run it in the pipeline, and require passing tests before a definition can be activated. Without it, the first verification of a new product is the first customer, and mispriced products are discovered through complaints. The same discipline applies to rating logic, as described in this guide to building a modern rating engine.
How do you handle downstream propagation?
By deriving documents, notifications, accounting, and risk feeds from the product definition.
Every product touches statements, notifications, the general ledger, regulatory reporting, and risk models, and each of those becoming a manual addition per product is what makes launches slow. Derive them: statement and document content from templates parameterised by the definition, accounting mapping from classification rules rather than per-product decisions, and reporting and risk classification as attributes of the definition itself. Ledger mapping in particular benefits from being rules-driven, which connects to general ledger and subledger modernisation.
Why does deposit product design feed risk models?
Because behavioural assumptions about repricing and stability are shaped by product terms.
The Basel Committee's standards on interest rate risk in the banking book require economic value of equity and net interest income measures under standardised shocks, with extensive attention to behavioural modelling assumptions. Deposit products are where those assumptions live: notice periods, penalty structures, promotional expiry, and rate linkage all determine how balances behave when rates move. So the product definition is an input to risk measurement rather than a downstream consumer of it, and a new product should propagate its behavioural characteristics into the risk model deliberately. That connection is developed in ALM and IRRBB system design.
How should delivery be sequenced?
Versioning first, then rate composition, then testing, then propagation, then self-service.
| Phase | Duration | Deliverable |
|---|---|---|
| Product model and versioning | 3 to 4 months | Immutable versions, effective dating, account version references |
| Legacy variant inventory | 1 to 2 months | Every closed variant documented and test-covered |
| Rate component structure | 2 to 3 months | Composable rates with effective dates and expiry |
| Configuration test harness | 2 months | Scenario-based verification in the pipeline |
| Rate change orchestration | 2 months | Notice, communication, effective dating, recalculation as one process |
| Downstream derivation | 3 to 5 months | Documents, notifications, ledger mapping, reporting from the definition |
| Product self-service | 2 to 3 months | Product teams define and test without engineering |
Legacy variant inventory sits early deliberately. It is unglamorous, it is the main source of regression risk in any product platform change, and doing it late means discovering during migration that nobody knows how a 1998 product calculates its bonus.
Which metrics matter?
Time to launch, share of launch work that is configuration, legacy variant coverage, rate change defects, and configuration test coverage.
Report elapsed time from product approval to live, split by phase, since that split shows where the constraint actually is. Track the share of a launch that required code changes, which is the engine's real effectiveness measure. Report legacy variant test coverage, because that number is your regression exposure. Count rate change defects, particularly notice failures and accrual boundary errors, as those are customer-affecting. Measure configuration test coverage and the share of definitions activated with passing tests. And monitor the distribution of customers across product versions and rates, since that is both a conduct view and a signal of how much legacy complexity the platform is carrying.
Deposit products look simple and accumulate complexity in a way few systems match: decades of variants, terms that cannot change, and rate structures that combine four components. The engines that make launches fast are the ones where versioning is structural, configuration is genuinely testable, and everything the product touches is derived from one definition rather than added by hand.
Frequently Asked Questions
Why does launching a deposit product take months?
Because configuration usually means development. Product setup, accounting mapping, statement content, notifications, and downstream propagation each require code changes rather than parameters.
What is the core requirement of a product engine?
Versioning. Every product needs immutable versions with effective dates, so existing customers stay on the terms they were sold while new customers get current terms.
Why is grandfathering the hardest part?
Because a bank accumulates dozens of closed product variants that must keep working correctly for decades, and every platform change has to preserve their behaviour.
Why is a rate change a process rather than a field update?
Because it triggers notice obligations, customer communications, effective dating, accrual recalculation, and downstream reporting. Changing a number is the smallest part.
Where should the line between configuration and code sit?
Configuration covers parameters, tiers, dates, and rule selection from a defined vocabulary. Anything requiring new logic is code, and pretending otherwise creates an unmaintainable language.
What is the missing capability in most product engines?
Testing configuration. Teams build the ability to define products and not the ability to verify a definition behaves correctly before it reaches customers.
How does the product engine relate to interest calculation?
The engine defines terms and the calculation engine applies them. Keeping them separate means a rate structure change does not risk the accrual logic.
Why does deposit product design feed risk models?
Because behavioural assumptions about repricing and balance stability drive interest rate risk measurement, and product terms determine how those behaviours can arise.
