Digital banking platform engineering for retail, commercial and business banking, designed around what your core can actually do and explicit about where the gap gets filled.
The experience is specified first: real-time balances, instant transfers, account opening in minutes, full transaction history, a product change that takes effect now. Then the core banking system is asked to support it.
Take the capabilities a modern digital proposition is expected to include and set them against what a typical core banking estate actually supports. The third column is where the work goes.
Two systems believe they know the balance
And the customer is shown whichever answers first.
Channels are visually consistent and not continuous
The same journey restarts when the customer switches.
Authentication is the biggest source of failure
And it is rarely owned as a product in its own right.
Legacy dependencies set the pace
A release cycle somewhere else becomes yours.
Integration is point to point
So each new channel multiplies the connections.
Peak load is predictable and still a problem
Pay day, month end, and the first of the month.
Availability is managed as operations
Rather than designed as the product feature it is.
Self-service displaced work rather than removing it
Call volumes fell and the remaining calls got harder.
Ask where the balance shown in your app is calculated. Not where it comes from, where it is calculated. If any part of the arithmetic happens in the channel layer, in a cache or in a service that was built to make the screen work, then the institution has a second balance with its own logic and its own defects, and the two will diverge under exactly the conditions that produce a complaint. That question takes ten minutes and it locates the most consequential architectural decision on the estate.
The usual sequence is to design the experience, then discover the constraints during build, then negotiate the experience back down. That sequence is expensive and it produces the workarounds described in section 2.
The alternative costs a few weeks at the start: establish what the core can provide, at what latency, at what load, and through what interface, and design the journeys knowing it.
Step 1
Assess the platform and the estate as it is
Step 2
Establish what the core can actually provide
Step 3
Map the journeys, with the constraint visible on each
Step 4
Decide where each missing capability will live
Step 5
Design the API and integration strategy
Step 6
Design identity and authentication as a product
Step 7
Establish the shared state model for continuity
Step 8
Build in phases that each deliver a working journey
Step 9
Integrate with the core and the surrounding systems
Step 10
Test for load, failure and degradation, not only function
Step 11
Deploy with observability and a rollback that has been used
Step 12
Monitor availability, completion, failure and adoption
Ask for authentication failure rates broken down by reason, device and customer segment. If the answer is a single success rate, the most-used journey on the estate is being managed with one number. The breakdown almost always shows a device, a method or a segment failing at several times the average, and the affected customers are usually the ones with the fewest alternatives. That data already exists in the logs and it is rarely assembled, which makes it one of the cheapest service improvements available.
Grouped by what each part is responsible for. The middle group is the one that decides whether the estate stays coherent, and it is the one most often assembled by accident.
Channels and experience
Web and mobile banking for retail, business and commercial segments, which have genuinely different requirements rather than different themes
Digital account servicing: standing orders, limits, cards, statements, preferences and the long tail of requests that drive contact volume
Digital account opening, integrated with verification as described on our KYC & Customer Due Diligence page
Self-service journeys designed around completion rather than submission, which is the distinction that decides whether contact volume falls
Personalisation bounded by permitted purpose, under the position set out on our Customer & Transaction Analytics page
The platform layer
An API layer with versioned contracts, consumed identically by every channel, so a new channel is a consumer rather than a project
Shared journey state and session continuity, held centrally and durably
Identity, authentication and entitlement, designed as a product with its own metrics
Workflow orchestration for requests that cross systems or need a human step
Any capability the core does not provide, held explicitly and reconciled rather than accumulated in a channel
Integration and resilience
Core banking integration within what the core can tolerate, on the patterns described on our Banking Data Platform Engineering page
Event-driven services where the interaction is genuinely event-driven, and request-response where it is not
Graceful degradation, so a failed dependency removes a feature rather than the application
Observability from the customer’s position rather than from the server’s, which are different measurements
Capacity design against the banking calendar: pay dates, month end and the first working day
These are usually scoped as one platform with several journeys. The third column is the point of the table: each one is limited by something different, and almost never by the front end.
| Journey | What it needs | What actually limits it |
|---|---|---|
| Retail banking | Balance, history, payments, servicing | Core latency and history retention |
| Business banking | Multiple users, mandates, approvals | Entitlement modelling, not the interface |
| Commercial banking | Complex structures, bespoke arrangements | Data that lives in people and documents |
| Digital account opening | Verification, decision, funding, activation | Third-party checks and the hand-off |
| Account servicing | Many small requests, end to end | Downstream systems with manual steps |
| Transaction management | Search, dispute, repeat, schedule | History depth and transaction meaning |
| Self-service support | Status, resolution, escalation | Whether operations can actually complete it |
A digital banking platform depends on systems it does not control: the core, payment rails, verification providers, card processors, credit bureaux, messaging gateways. Each of them will be unavailable at some point and most of them will be slow before they are unavailable.
The architectural question is not how to prevent that. It is what the customer experiences when it happens, and that is a design decision that has to be made per dependency rather than discovered during an incident.
An API gateway and a contract-first API layer, versioned, with every channel as an equal consumer rather than a special case
Services decomposed by business capability where that helps, and left alone where it does not, since a distributed version of a tangle is still a tangle
Event-driven integration for genuine events, and request-response for a question that needs an answer now
Identity and access management, federated where appropriate, as the platform-wide service rather than per channel
Graceful degradation per dependency: a defined, tested behaviour for each one being slow, partial or absent
Caching with bounded, visible staleness, used for display and never as an authority
Observability measured from the customer’s position, including client-side timing, since server-side latency is not what the customer experiences
And core and enterprise integration on the patterns described on our Banking Data Platform Engineering page
Ask what your app does when the core is unavailable. Not what the error says, what the customer can still do. In a well-designed platform a core outage removes balances and payments and leaves card controls, statements, secure messaging and the ability to report a lost card working. In most platforms it removes everything, because nothing was designed to work without it. That answer tells you whether degradation was designed or inherited, and it is the difference between a bad hour and a bad day.
Which banking, payments, accessibility, consumer protection and operational resilience requirements apply, and what controls they call for, are determined by your compliance, legal, risk and security functions, based on your operating markets. We do not interpret those requirements and this page does not state which apply to you.
Technology supports a control framework. It does not independently establish one, and no platform makes an institution compliant.
Secure engineering
- Security requirements set by your security function and implemented in the delivery process rather than tested for at the end
- Threat modelling per journey, with the payment and authentication journeys treated as the highest value targets
- Secrets, keys and certificates managed as operational assets with owned expiry, which is a common and avoidable outage cause
- Dependency and component management, since a platform inherits the vulnerabilities of what it is built from
Identity, access and data
- Authentication and step-up implemented to your standards, with the recovery path designed to the same standard as enrolment
- Entitlement enforced server side on every request, never inferred from what the interface displayed
- Customer data minimised in the channel layer, since data held there is data exposed on the most attacked surface
- Session handling, device binding and logout behaviour defined explicitly, including on shared devices
Resilience and continuity
- Degradation behaviour defined and tested per dependency, as described in section 6
- Recovery objectives agreed with the business per journey rather than one objective for the platform
- Incident response with named ownership, rehearsed rather than documented
- Change and release control proportionate to the journey, so a content change and a payment change are not the same process
Accessibility and fairness
- Accessibility treated as a requirement from design, tested with assistive technology and with real users rather than only against a checklist
- Authentication methods reviewed for exclusion, because several common methods are unusable for some customers and the exclusion is invisible in averages
- Digital-only journeys reviewed for the customers who cannot complete them, with an alternative that is not a worse service
- Audit trails over customer-affecting actions, access, consent and configuration change
Platform monitoring reports uptime and server response times, both measured inside the data centre. The customer experiences a journey on a device on a network, and the two sets of numbers can disagree completely.
| Failure | How it presents |
|---|---|
| Uptime is green and a journey is broken | Platform available, one step failing silently |
| A dependency is slow rather than down | Latency rising, then threads, then everything |
| Authentication fails for one segment | Average success healthy, a group locked out |
| Abandonment concentrated at one step | Funnel reported end to end, cause invisible |
| Stale cache treated as authoritative | Two balances, and a complaint |
| Contact volume fell and handling time rose | A reported success and a worse service |
| Peak degradation on a known date | Predictable load, unplanned capacity |
| A certificate or secret expired | An outage with a trivial cause and no owner |
The outcomes below follow from three choices: decide deliberately where the capability the core lacks will live, build shared state rather than matching screens, and design degradation per dependency.
Digital journeys that complete rather than submit, measured end to end including the steps after approval
Channel integration that preserves state, so a customer who switches does not start again
Service delivered faster where the constraint was the platform, and the constraint named where it was not
Scalable operations, because the API layer makes a new channel a consumer rather than a programme
Reduced platform complexity, through one integration pattern rather than one per channel
Availability that holds on the days load is predictable
One authoritative answer per customer fact, with any derived copy labelled and reconciled
We will take one journey and establish four things: what the core can actually provide, where the gap is being filled today, what the customer sees when a dependency fails, and where in the journey customers are actually stopping. You get the findings whether or not we build anything.
CaliberFocus builds digital banking platforms where the gap between the experience and the core is a named architectural decision rather than an accumulation of workarounds. We establish core constraints before journeys are designed, hold journey state centrally for true continuity, treat authentication as a product, and design what customers see when a dependency fails.
- Core constraints established before journeys are designed
- Shared journey state so customers never start again across channels
- Authentication measured and designed as a product
- Degradation designed and tested per dependency
Security & Compliance
