Design the institution before you select the core
Choosing a system without (or before) understanding the strategy it is supposed to enable is one of the most common mistakes in buying a core system.
A core platform only facilitates business and operating change; it does not define it. Before entering into vendor shortlists and feature shopping, the institution should first ask what type of organisation they are trying to build.
βSome banks just want to mirror their existing operating model on a new platform. We really challenge them to rethink it.β
A 4th-generation core should not simply support todayβs organisation. It should facilitate how the institution intends to operate and compete in the future.
Today, differentiation sits increasingly in customer lifecycle orchestration, coordinating products, pricing, risk and engagement in real time. Expectations are personalised and intelligence operates continuously. Increasingly, agentic workflows will act across systems rather than simply surface insights.
Supporting this shift requires rethinking capabilities before selecting technology.
From strategy to architecture
Core platform decisions must follow a clear sequence: strategy first, capabilities second, architecture third. Institutions that reverse this order often design their strategy around the limitations of a platform rather than the outcomes they intend to deliver.
1. Define the strategic outcomes
Leadership must first define the outcomes the institution intends to achieve over the next decade. Institutions adopting modern core platforms are typically pursuing four strategic shifts:
- Greater speed and agility: faster time-to-market for new products and services
- New distribution and revenue models: ecosystem partnerships and embedded finance channels
- Expansion without platform constraint: entering new markets or segments without rebuilding the platform
- A move from product-centric to customer-centric banking: personalised, lifecycle-driven engagement
Together, these shifts define the direction the institution intends to take.
2. Identify the capabilities required
Once strategic intent is clear, the next step is to define the operational capabilities required to deliver it. An institution pursuing ecosystem distribution and rapid product innovation must be able to:
- configure and launch new products without core redevelopment
- respond to customer events and risk signals in real time
- enter new markets and geographies quickly while adapting to regional regulatory requirements
- maintain a unified, continuously updated view of the customer
- integrate seamlessly with partners, fintechs and third-party platforms
- scale services independently as demand changes
This is not a question of buying product features, but rather effecting change.
3. Define the architectural principles
Architecture should only enter the discussion once these capabilities are clearly defined, so the platform can be designed to support them.
Rapid product configuration
Composable product architecture with product logic separated from the core ledger
Real-time responsiveness to events
Event-driven processing across services
Continuous customer insight
Real-time data architecture with access to live transactional data
Ecosystem connectivity
API-first platform designed for external integration
Flexible scaling of services
Cloud-native, horizontally scalable microservices infrastructure
If the architecture does not support the intended operating model, strategy will either stall or quietly adapt to platform limitations.
The role of the proof of concept
Once strategic outcomes, capabilities and architectural principles are defined, platform evaluation becomes far more disciplined.
At this stage, a well-designed proof of concept (POC) provides critical validation. Much like a test drive before purchasing a car, the objective is not to inspect features but to understand how the platform performs under real operating conditions.
Most platforms can demonstrate functionality. The real question is whether the platform can support the operating model the institution intends to build.
A meaningful POC therefore focuses on validating capabilities under realistic conditions. This typically includes testing:
- how quickly products can be configured or modified
- how the platform responds to real-time events and data updates
- how easily it integrates with existing systems and partners
- how services scale under realistic operational conditions
By structuring the POC around real use cases, institutions move beyond feature comparisons and see how a platform behaves in practice. It also provides a valuable opportunity to see how the institution and vendor work together, testing not just the technology, but the partnership approach, ways of working and cultural fit that will ultimately shape the success of the programme.
βIn selecting partners, we put culture first and technology second. We wanted teams whose people wake up every day to solve problems together, because when things get hard, you donβt need a vendor behind a contract, you need a partner.β
When executed properly, a POC allows institutions to confirm that a platform can support the capabilities required for their future operating model before committing to the platform that will underpin how the institution is built and run.
βWe went through a very detailed process, defining business requirements, technical requirements, and making sure everything we needed was clearly captured. After that, we requested a proof of concept using the real system to validate whether it truly met our expectations.β
Buyer checkpoint
Understand the model you are committing to
- 01Does this architecture support our intended competitive positioning?
- 02Can we move from product silos to lifecycle coordination without structural workarounds?
- 03Can we integrate ecosystem partners without duplicating logic or weakening ledger authority?
- 04Will intelligence, automation and risk controls operate on real-time events rather than delayed extracts?
- 05Have we validated these claims under real conditions, beyond demonstrations?
Architecture should expand strategic freedom. If it narrows future options, the next constraint has already been introduced.