Introduction
"We are replacing the core banking system" is the heaviest sentence in bank IT. It is often compared to performing a heart transplant while the patient runs a marathon. And yet banks around the world keep climbing onto this operating table for a clear reason: at some point, the cost and risk of keeping the legacy core exceeds the cost and risk of replacing it.
In this article we compare the drivers and approaches of core banking modernization, then cover core decomposition strategy, the cloud-native core wave, the regulatory environment peculiar to Korea, data migration and cutover risk management, organizational transformation, and the failure patterns that keep repeating. This is not a recommendation of any vendor or solution, nor investment or legal advice. Regulatory matters change over time, so always verify against the latest primary sources.
The Reality of Legacy Core Banking
The Inheritance of COBOL and Mainframes
A large share of the world's major banks still run COBOL cores on mainframes. Systems built in the 1970s and 80s, extended repeatedly, have commonly grown into codebases of tens of millions of lines. These systems are a paradox: "old but unbreakable." Their stability and transaction throughput, proven by decades of operation, are real — but the following structural burdens accumulate.
- The talent cliff: people who know COBOL and the institution's homegrown frameworks retire, and almost nobody new arrives. Fossilization sets in — "the code exists, but nobody knows why."
- Change cost: even adding a simple product condition takes weeks of impact analysis, and releases get bundled into quarterly trains.
- The integration wall: impedance against modern integration styles — real-time APIs, event streaming — grows, so middleware layers pile up.
The Typical Shape of a Legacy Core
To know exactly what we are modernizing, picture the typical legacy core.
+--------------------------------------------------------------+
| Monolithic core (mainframe/Unix) |
| |
| [Online area] [Batch area] |
| TP monitor (transaction control) JCL/scheduler driven |
| Deposit/lending/FX txn modules Thousands of EOD/EOM |
| (product logic + ledger update jobs (interest, closing,|
| + posting mixed in one program) reports, recon, feeds) |
| |
| [Shared data] |
| Hierarchical/relational DB + VSAM-like files + thousands |
| of code tables |
| Inter-module comms: shared memory, file interfaces, |
| point-to-point messages |
+--------------------------------------------------------------+
The problem with this structure is not performance (performance is generally excellent). The problem is coupling. Product logic, calculation, ledger recording, and accounting form one lump that cannot be changed piecemeal, and thousands of batch jobs are entangled through file interfaces, so impact analysis itself becomes archaeology.
The History of Korean Next-Generation Projects
Korean banking took a distinctive path. From the early-to-mid 2000s, under the name "next generation," banks repeatedly performed big-bang rebuilds migrating from mainframes to Unix (later Linux/x86). First-generation projects (2000s), second-generation (2010s), and for some banks a third generation — mega-projects typically running three to five years with budgets in the hundreds of millions of dollars equivalent. As a result, Korean commercial bank cores are further off the mainframe than the global average, but fatigue with the model itself — "a big-bang rebuild every several years" (cost, organizational exhaustion, big-bang cutover risk) — accumulated alongside. This is the backdrop for the recent shift of the conversation toward incremental modernization and cloud adoption rather than big bangs.
The Drivers of Modernization — Why Now
| Driver | Specifics |
| --- | --- |
| Cost structure | Mainframe licensing/maintenance costs, ever-rising unit cost of change |
| Talent risk | Retirement of legacy-skilled staff, unattractiveness in the hiring market |
| Agility | Demands to shorten product launch cycles (from months to weeks/days) |
| Competitive pressure | The arrival of internet-only banks — low IT cost base, fast experimentation |
| Channel shifts | Mobile-first, open banking, embedded finance changing traffic patterns |
| Regulatory change | Gradual relaxation of cloud usage rules, rationalization of network separation |
| Data leverage | Demands for real-time data-driven personalization and risk management |
In Korea especially, the shock of internet-only banks was significant. Watching newly built banks — Linux and open source from day one — run their cores with far fewer people and far less money while experimenting rapidly with products shook the conventional wisdom that "core banking is inherently heavy and slow."
One caution when cataloguing drivers: "it is old, therefore we replace it" cannot be a driver. To persuade leadership and justify multi-year investment, each driver must be translated into a measurable goal (cut product launch lead time by N days, reduce operating cost by N percent, retire a specific talent risk by a deadline), and those goals become the prioritization yardstick for every subsequent phase.
Comparing Approaches — Four Roads
Core modernization approaches sort into four broad families.
| Approach | Summary | Strengths | Weaknesses/Risks | Fits When |
| --- | --- | --- | --- | --- |
| Big-bang rebuild | Full rebuild, then switch over at once | Coherent architecture, simple operations afterward | Maximal cutover risk, years of frozen value, chronic budget overruns | Legacy is at its limit and the org has mega-project experience |
| Incremental strangler | New system absorbs legacy function by function | Distributed risk, early value delivery, learning feeds back | Complexity of coexistence, risk of dragging on | Domain boundaries are separable and a long-term roadmap can be sustained |
| Hollow the core | Shrink the core to a thin ledger, extract everything else | Minimal core change keeps risk contained | May merely extend the life of the core itself | Core is stable but peripheral agility is urgent |
| Greenfield parallel bank | Build a separate new bank/brand on a new core, then migrate customers | Design free of legacy constraints, fast validation | Double running costs, hard migration of existing customers | Paired with new business / new segment plays |
Real projects are mixtures. A realistic roadmap often looks like: "launch new deposit products on the new core (greenfield) + migrate existing products as they roll over at maturity (strangler) + freeze the legacy down to ledger functions only (hollow)."
The Structure of the Strangler Pattern
+---------------------+
Channels/Gateway->| Routing facade |
| (split by product/ |
| account) |
+----+-----------+----+
| |
old accounts/ | | new accounts/
old products | | new products
+---------v--+ +--v-----------+
| Legacy core | | New core |
| (frozen, | | (growing, |
| shrinking) | | expanding) |
+---------+--+ +--+-----------+
| |
+---------v-----------v----------+
| Unified ledger view / info |
| layer sync (single view of |
| balances and txns on both) |
+--------------------------------+
The strangler stands or falls on the design of the routing facade. The core challenges: channels must not need to know which core holds which account, and transactions spanning both sides (a transfer from an old account to a new one) must stay consistent.
Core Decomposition Strategy — What to Split, and How
Separating the Product Factory
The chief culprit behind bloated legacy cores is product logic baked into ledger-processing code. Modern core design externalizes product definitions (rate structures, fees, conditions, limits) into data and configuration — a product factory. The goal is that launching a new product becomes "registering product metadata," not "deploying code." The preferential-rate rule engine covered in the previous article can be seen as part of the product factory.
Separating the Ledger — the Thin Core
[Traditional monolithic core] [Decomposed core]
+--------------------+ +------------------+
| Channel handling | | Product factory | <- product defs/rules
| Product logic | +------------------+
| Interest/fee calc | +------------------+
| Ledger recording | => | Pricing/interest | <- calculation only
| Customer info | | engine |
| Accounting entries | +------------------+
| Reports | +------------------+
+--------------------+ | Thin ledger | <- balances/txns only
| (the core) |
+------------------+
+------------------+
| Customer master |
| (separate) |
+------------------+
+------------------+
| Accounting hub |
| (separate) |
+------------------+
The principle of decomposition: keep the ledger small and hard to the very end. Keep only the essence — balances and transaction records — and pull calculation (interest, fees), judgment (limits, conditions), and presentation (reports, inquiries) outside. The smaller the ledger, the easier the verification; the easier the verification, the safer the migration.
Event-Driven Integration
Wiring the decomposed components together with events is today's orthodoxy. When the ledger finalizes a transaction, it publishes an event (credit completed, account closed), and the information layer, notifications, accounting hub, and risk systems each subscribe.
[Ledger core] --publish--> [Event stream (Kafka etc.)] --subscribe--> [Info layer load]
+--subscribe--> [Notifications/push]
+--subscribe--> [Accounting hub]
+--subscribe--> [FDS/risk]
In the financial domain, however, event-driven integration demands stricter discipline than ordinary web services.
- Atomicity of ledger commit and event publication: the outbox pattern (write the event to a table inside the ledger transaction, with a separate relay publishing it) is the de facto standard.
- Ordering and idempotency: events for the same account must preserve order (partitioning keyed by account), and subscribers must assume duplicates and be idempotent.
- Replayability: when a subscriber fails, it must be able to re-consume from a point in time, and event schema backward compatibility must be managed.
Deciding the Order of Decomposition
What to peel off first is best evaluated along two axes.
| Axis | Question | Examples |
| --- | --- | --- |
| Ease of separation | Is coupling to ledger transactions weak | Reports/inquiries (easy) vs. withdrawal validation (hard) |
| Rate of change | Does business demand change it often | Product terms/preferential rates (high) vs. posting rules (low) |
Start with what changes often and separates easily (inquiry APIs, product rules, notifications) to create early wins, and tackle the ledger proper — hard to separate, rarely changing — last. Projects that start with the hardest part, the ledger, tend to pile up risk without delivering value and lose momentum.
The Cloud-Native Core Banking Wave
From the late 2010s, the movement toward "core banking as SaaS / cloud native" gathered real force. Summarizing the commonly cited players, within the bounds of what is well known (not a recommendation; capabilities and strategies keep changing, so check official sources):
- Thought Machine (Vault Core): a newer core emphasizing cloud-native design and a product definition method called smart contracts (product logic described as code contracts). Frequently mentioned in large banks' next-core experiments.
- Mambu: a flagship SaaS core banking vendor, championing composable banking (assembling the capabilities you need). Many fast-launch stories among neobanks and fintechs.
- Traditional heavyweights — Temenos, FIS, Finastra — are responding with cloud-transition versions of their suites.
Common patterns of cloud-native cores:
1. Product definition as code/config: products are declarative definitions outside the core, shortening launch cycles.
2. API first: every capability exposed as an API, easing channel and partner integration.
3. Horizontal scaling: partitioning by account scales throughput by adding nodes.
4. Real-time ledgers: less batch-centric design; interest accrual and similar work tends to move to real-time or near-real-time.
There are also points to view coldly. Completed cases of a large incumbent bank moving its entire ledger to a young SaaS core remain few; partial adoption (specific product families, new brands) under validation is the norm. The practitioner-calibrated view is not "cloud-native core = finished product ready to install" but "promising, with a high cost of validation."
Korean Particularities — Regulation as a Variable
Designing core modernization in Korea cannot ignore the regulatory environment. The broad strokes (details are revised frequently — always check the latest texts and interpretations from the Financial Services Commission and the Financial Supervisory Service):
- The Regulation on Supervision of Electronic Financial Transactions: the key regulation setting safety standards for financial-company IT. It imposes requirements on staffing and organization, facilities, information processing systems, and disaster recovery (recovery time objectives for critical work), acting as constraints on architecture.
- Network separation: the rule demanding separation of internal business networks from the internet, which heavily affected developer productivity (open source usage, SaaS development tools). In recent years, regulatory sandboxes and staged improvements have brought exceptions and rationalization for cloud development environments, generative AI usage, and more.
- Cloud usage rules: in the past, cloud for critical systems was effectively impossible; through successive amendments, the permitted scope has widened step by step on the basis of materiality assessments and prior-reporting regimes. Still, wholesale movement of core-ledger-grade systems to public cloud is generally approached conservatively across the industry.
The strategic implication is clear. The realistic path in Korea is often "peripherals first to the cloud (channels, information layer, new business); for the core, decomposition and standardization first" — and the pace of regulatory change must be built into the roadmap as a primary variable from day one.
Data Migration Strategy — The Craft of Moving a Ledger
The greatest obstacle in core modernization is not code but data. Tens of millions of accounts, billions of historical transactions, and balances that change "even at this very moment" must move.
Dual Write / Parallel Run
Phase 1: legacy is master, new core is the shadow
[Txns] --> [Legacy ledger (authoritative)] --replicate/replay--> [New ledger (shadow)]
|
[Daily full reconciliation: balances/interest/fees comparison report]
Phase 2: after trust is earned, swap roles (per product family / customer segment)
[Txns] --> [New ledger (authoritative)] --replicate--> [Legacy ledger (shadow, fallback)]
Phase 3: freeze legacy, keep read-only archive, then retire
The core disciplines:
1. Verify in full, not by sample: sampling is a trap. In areas with many condition combinations, such as interest calculation, full-account comparison is the rule, and each difference gets a classification code so convergence can be tracked (define the cutover gate as something like "zero differences sustained for N consecutive days").
2. Replayable migration: structure it as initial load + change synchronization (CDC) + final sync just before cutover, with every stage re-runnable from scratch on failure.
3. Specify semantic mappings: legacy status codes, day-count conventions, and truncation policies may not map 1:1 to the new core. Write the mapping rules as a specification, and agree with the business on how to treat conversion losses (for example, special statuses that exist only in the legacy).
4. Decide on history: whether to move full transaction history into the new core, or keep it in a read-only archive with the new core starting from opening balances, weighs cost, regulatory retention duties, and customer experience together.
The Shape of Parallel Reconciliation Queries
The substance of full reconciliation is surprisingly humble SQL. A skeleton for comparing old and new ledgers daily:
-- daily full balance reconciliation: legacy snapshot vs. new core snapshot
SELECT COALESCE(l.account_no, n.account_no) AS account_no,
l.balance AS legacy_balance,
n.balance AS new_balance,
COALESCE(l.balance, 0) - COALESCE(n.balance, 0) AS diff,
CASE
WHEN l.account_no IS NULL THEN 'NEW_ONLY' -- exists only in new
WHEN n.account_no IS NULL THEN 'LEGACY_ONLY' -- exists only in legacy
WHEN l.balance <> n.balance THEN 'MISMATCH'
ELSE 'OK'
END AS recon_status
FROM legacy_balance_snapshot l
FULL OUTER JOIN new_core_balance_snapshot n
ON l.account_no = n.account_no
AND l.snapshot_date = n.snapshot_date
WHERE l.snapshot_date = DATE '2026-06-12'
AND (l.balance IS DISTINCT FROM n.balance
OR l.account_no IS NULL OR n.account_no IS NULL);
-- classify and aggregate differences: for convergence tracking
SELECT recon_status, diff_reason_code, COUNT(*) AS cnt,
SUM(ABS(diff)) AS abs_diff_sum
FROM daily_recon_result
WHERE snapshot_date = DATE '2026-06-12'
GROUP BY recon_status, diff_reason_code
ORDER BY cnt DESC;
The point is the difference reason code. Classify differences — "truncation policy difference," "legacy special status," "timing difference (open items)" — and you can track which differences are design-accepted (a documented allowance list) and which are defects. A difference report produced automatically every day, with a trend line bending downward: that is the proof that parallel verification is alive.
Cutover Design
| Cutover Style | Description | Risk Profile |
| --- | --- | --- |
| All-at-once (big bang) | Full switch over a weekend or similar | Short but intense; narrow rollback window |
| By product family | e.g. new installment savings first | Coexistence complexity, distributed risk |
| By customer segment | e.g. new customers first | Splitting multi-account customers is awkward |
| Maturity rollover | Re-contract onto the new core at maturity | Slowest but safest axis |
Whatever the style, the rollback plan must be a deliverable of equal rank with the cutover plan. A rollback plan never validated by rehearsal — "until what point, if which conditions break, by which procedure do we revert" — is just a document. Large migrations typically run several full rehearsals (including full-volume data migration rehearsals), measuring elapsed time at each to confirm slack in the cutover timeline.
A Sample Cutover-Weekend Timeline
The final weekend of a migration with big-bang elements usually moves to a timetable like this.
Friday close of business
T+0h : confirm legacy EOD completed normally (predecessor gate)
T+1h : block new transactions (service notice), channels to maintenance mode
T+2h : final change sync (drain CDC), fix the quiesce point of both ledgers
T+3h : run full reconciliation (balances/accrued interest/limits/status)
T+6h : reconciliation verdict meeting -> GO / NO-GO decision
[GO] : switch routing, start transactions on the new core (internal test txns first)
T+8h : open channels in stages (staff -> some customer segments -> all)
T+24h : first-business-day monitoring regime (war room) active
T+72h : stability verdict, stand down the war room or final rollback deadline
[NO-GO] : execute the pre-defined rollback procedure, return to legacy, analyze
The most important line in this timetable is the GO/NO-GO verdict meeting. Only if the verdict criteria (tolerances for reconciliation differences, pass rates for mandatory scenarios) were agreed in writing beforehand can you prevent improvised decisions in an exhausted meeting room at 4 a.m.
Risk Management — Staged Gates
A modernization program is controlled through staged go/no-go gates.
[Example gates]
G1 Design validation : PoC of key transaction scenarios on the new core, performance targets agreed
G2 Parallel start : shadow mode live, full reconciliation regime live
G3 Partial cutover : low-risk product families switched, ops regime (monitoring/incident) validated
G4 Main cutover : core product families switched; completed rollback rehearsal is a precondition
G5 Legacy freeze : new transactions blocked, read-only conversion, retention plan fixed
Quantifying each gate's verdict criteria matters. Without criteria like "zero parallel reconciliation differences for N consecutive days," "new core P99 response time target met," "incident drill passed," gates get breached by schedule pressure.
Transforming the Organization and Its People
Harder than the technical migration is the organizational one.
- Designing the dual-skill period: for the years old and new coexist, you need both people who know the legacy and people who know the new stack. If you fail to create a path that redeploys legacy staff as "domain experts of the migration" (documenting domain knowledge, owning business validation of the new core), legacy knowledge evaporates in the late phases — an accident in its own right.
- Shifting the operating model: a decomposed core changes how you operate. The move from a central operations team supervising batch runs to per-service on-call and SRE practices has to come along.
- Joint ownership with the business: the product factory is a tool "built by IT, used by the business." Transferring responsibility for product definitions to the business — validation environments, approval workflows, training — is inside the project scope.
- Managing outsourcing dependence: Korean next-generation projects have traditionally been led by large system integrators. Incremental modernization demands in-house capability sustained over years; a structure where "the people leave when the project ends" cannot survive the operating phase. Insource the design and operation of critical components (ledger, product factory) and confine outsourcing to modules with clear boundaries.
Organizational progress is harder to measure than technical progress, but at minimum you should be able to answer, at every stage: "can internal staff alone diagnose and recover a new-core incident?"
Failure Patterns — The Recurring Traps
1. The curse of functional equivalence: set the goal as "100 percent identical to current behavior," and you end up replicating the legacy's accidental behaviors (bug-like specifications included), costs explode, and the point of modernizing evaporates. Building an allowed-differences list and agreeing it with the business is mandatory.
2. Politicized big-bang dates: the cutover date gets fixed first by an executive announcement and quality becomes subordinate to schedule. The vaccine is quantified gate criteria and governance agreement on the principle "criteria over calendar."
3. Skipping parallel verification: shorten the shadow period under schedule pressure, and latent defects detonate after cutover in low-frequency events such as interest settlement and month-end closing. Including at least one quarterly settlement inside the parallel period is the safe practice.
4. Underestimating data quality: integrity problems in legacy data (orphan records, code mismatches) demand business judgment, not just migration tooling. Unless data cleansing starts as its own track early in the project, it becomes the end-stage bottleneck.
5. New-technology maximalism: adopt patterns like event sourcing and MSA "as ends in themselves," and distributed-systems complexity translates directly into ledger consistency risk. The criterion for every technology choice must be whether it serves the essence of the core: the money must be right.
6. Reproducing vendor lock-in: escaping mainframe lock-in only to become more deeply locked into one cloud or one SaaS core. Evaluate exit costs (data export, portability of product definitions) at the contract stage.
7. Deprioritizing non-functional requirements: defer performance, disaster recovery, and security with "we will tune later," and late-stage performance tests force architecture-level rework. Include peak load and failure scenarios from the earliest PoC.
8. A split migration organization: the new-core build team and the legacy operations team separated into different reporting lines, severing information flow. Analyzing reconciliation differences needs knowledge from both sides, so a blended team holding a shared goal (the difference-convergence metric) works best.
Metrics That Measure Progress
A multi-year program must be managed by metrics, not vibes. A useful set:
| Category | Metric | Why It Matters |
| --- | --- | --- |
| Value delivery | Products launched on the new core, product launch lead time | Whether modernization touches the business |
| Strangler progress | Share of transactions on the new core (count/amount), migrated account ratio | Real progress of absorption |
| Quality | Trend of parallel reconciliation differences, distribution by reason | Cutover readiness |
| Stability | New core availability, P99 latency, incident count | Building operational trust |
| Legacy shrinkage | Legacy change requests, batch job count, license costs | Whether the freeze is real |
| Organization | Share of staff fluent in the new stack, documentation rate of legacy domain knowledge | Countering the talent cliff |
"Legacy change request count" in particular is a hidden gem of a metric. If modernization is underway but legacy changes are not declining, new functionality is still flowing into the legacy — a warning that you are double-investing rather than absorbing. A declared "freeze on new legacy features" with an exception-approval process keeps this metric honest.
Glossary
| Term | English | Meaning |
| --- | --- | --- |
| Next-generation project | Cha-sedae | The Korean umbrella term for full core-rebuild mega-projects |
| Big-bang cutover | Big-bang cutover | Switching everything at a single point in time |
| Strangler | Strangler fig pattern | The new system gradually absorbing the legacy |
| Product factory | Product factory | Componentizing product definitions as data/config |
| Thin ledger | Thin ledger | A minimal core keeping only balances and transactions |
| Dual write | Dual write / parallel run | A period of writing to both ledgers while verifying |
| Full reconciliation | Full reconciliation | Comparing every record, not samples |
| Cutover gate | Cutover gate | Quantified criteria for advancing a stage |
| Shadow mode | Shadow mode | The new core computing in parallel without authority |
| Rollover migration | Rollover migration | Moving contracts to the new core as they mature |
| Network separation | Network separation | The rule separating business networks from the internet |
| War room | War room | The concentrated monitoring and decision regime right after cutover |
A Sample Roadmap — A Hypothetical Mid-Size Bank, Five Years
Sketching the whole picture with a hypothetical scenario:
Year 1: foundations
- Core domain analysis; define ledger/product/calculation boundaries
- Build API gateway and event stream; attach adapters to the legacy
- Start the data cleansing track; formalize cloud governance (regulatory)
Year 2: periphery first
- Move the information layer and channels to cloud; relieve legacy load
- Build product factory v1; pilot one new deposit product on the new core
Year 3: shadow in parallel
- New core in shadow mode; full reconciliation regime in operation
- Pass at least one quarterly settlement under parallel verification
Year 4: staged cutover
- Switch low-risk product families in sequence; run maturity rollover alongside
- Operate rollback rehearsal and DR failover drill passes as gates
Year 5: legacy freeze and wrap-up
- Complete remaining product migration; legacy preserved read-only
- Finish the operating-model transition (SRE regime); retrospect and standardize
Real timelines, of course, vary widely with regulatory change, organizational capability, and priorities. The point is structure, not duration: the order in which value appears early (periphery, then new products, then parallel, then staged switch) and quantified gates at each stage must form the roadmap's skeleton.
One more addition: a roadmap is not a one-time deliverable. Operate it as a living document re-evaluated yearly against the pace of regulatory relaxation, validation results from the new core, and market conditions (rate environment, competitor moves). But however frequent the re-evaluation, beware revisions that loosen the gate criteria themselves. Dates may move; quality bars do not — that principle protects the program's credibility.
Closing Thoughts
Core banking modernization is less a technology project than a risk management program. Big bang versus incremental is not a religious war; it is an engineering judgment about the organization's risk-absorption capacity and the separability of its domains. What is unambiguous is the direction: ledgers small and hard, products as data, integration through events, migration under parallel verification. And whatever dazzling architecture you draw, the final question is the same one from the previous two articles: "Where in this transition could the money go wrong?" Only programs that can answer that question at every stage finish the heart transplant.
The ledger design and verification disciplines covered in the first two parts of this series (deposit system architecture, the interest calculation engine) are, in the end, also the common language that makes old and new systems comparable on this modernization journey. If your organization intends to replace its core, I recommend first checking whether you can describe your current core in that language.
References
- Martin Fowler - Strangler Fig Application: https://martinfowler.com/bliki/StranglerFigApplication.html
- Thought Machine official site: https://www.thoughtmachine.net
- Mambu official site: https://www.mambu.com
- Temenos official site: https://www.temenos.com
- BIS - working paper on fintech and market structure: https://www.bis.org/publ/work834.htm
- Financial Services Commission (Korea): https://www.fsc.go.kr
- Financial Supervisory Service (Korea): https://www.fss.or.kr
- Regulation on Supervision of Electronic Financial Transactions (Korean Law Information Center): https://www.law.go.kr
- Apache Kafka official documentation: https://kafka.apache.org/documentation/
- Microservices.io - Saga, Transactional Outbox patterns: https://microservices.io/patterns/data/transactional-outbox.html
- AWS financial services security and compliance: https://aws.amazon.com/financial-services/security-compliance/
- Financial Security Institute (Korea): https://www.fsec.or.kr
현재 단락 (1/254)
"We are replacing the core banking system" is the heaviest sentence in bank IT. It is often compared...