Česká spořitelna: core-banking integration and one customer view.

The challenge

Core banking systems are built for transactional integrity: balances must be exact, postings atomic, availability engineered to many nines. Those are the right priorities — and they are also why a core system makes a poor place to run customer relationships. Its data model is account-centric rather than person-centric, its interfaces are designed for machines rather than advisers, and one customer's relationship with the bank is typically scattered across products that each run on their own systems.

Front-line staff pay for this daily: serving a single customer can mean juggling several applications and mentally stitching the relationship together. And anything a bank changes here happens under constraints most industries never meet — bank secrecy, GDPR, strict security review, and transaction volumes that punish any integration built without discipline.

The published scope of our work with Česká spořitelna is: core-banking integration and unified customer data on Salesforce. Which core services were connected, at what volumes, and how the rollout was sequenced are exactly the details we keep for reference calls; what belongs on this page is the architecture pattern.

Our approach

Discovery in a bank starts with the interfaces: which core services exist, what protocols and contracts they expose, what their owners will and will not allow, and where the batch windows are. The design principle that follows is non-negotiable for us: Salesforce must never become a shadow core. Accounts and balances remain mastered in core banking; Salesforce holds the relationship.

We phase the build along the risk gradient. Read paths come first — a unified customer view that looks into the core — and carefully scoped write paths follow once the integration has proven itself in production. As on every Clouderia engagement, the delivery follows the Discover, Design, Build, Run method on our services page: increments ship tested, monitoring is in place before go-live, and the senior engineers who scoped the work stay through the Run phase.

Architecture

Every bank's estate differs, so this section stays at pattern level — the shape of the build rather than a client-specific diagram.

Reading the core without copying it

Wherever freshness matters, Salesforce reads the core through a service layer at request time rather than holding a copy. Replication is reserved for slow-moving reference data, and it is always paired with reconciliation checks. This keeps the compliance surface small: sensitive data that never lands in CRM never has to be governed there.

Write paths that respect the core

Anything that changes core state is treated as a money-grade integration: idempotency keys so retries cannot double-apply, backoff and circuit breakers so a struggling core system is not made worse, and fallout queues so failures become visible work items instead of silent losses. We wrote these patterns up in detail in our article on integrating Salesforce with core banking APIs safely, and the same family of discipline is what our TransactionHub product packages for PSD2 bank feeds and reconciliation.

Security and identity

Authentication, least-privilege integration users, field-level security and end-to-end auditability run through the whole design. We describe this qualitatively on purpose: every bank's security review sets its own bar, and the architecture has to clear it rather than argue with it.

Built for bank-scale volumes

Volume shapes every decision in this pattern. Calls to the core are batched and paginated rather than issued per record, hot lookups are cached with explicit freshness rules, and platform limits are treated as design inputs from day one rather than surprises in production. An integration that works in a demo and collapses under a morning's real traffic is the most expensive kind of failure a bank can ship.

One customer view

Unified customer data means identity resolution across product silos: matching rules, survivorship rules and a golden record that advisers and service teams can trust. The golden record serves engagement; the core remains the system of record for accounts and balances. The broader trade-offs behind these choices are covered in our integration practice and integration patterns article.

Outcome

No performance metrics are published for this engagement, and we do not invent numbers. The published result stands on its own: core-banking integration and unified customer data running on Salesforce.

Qualitatively, the pattern delivers three things a bank can build on. Advisers and service teams see the customer relationship in one place instead of assembling it from separate systems. The integration seam is observable and resilient, so operational issues surface as work items rather than mysteries. And because the core is read rather than copied, core systems keep evolving on their own schedule without dragging the CRM layer with them.

Related reading