Digital Transformation in Banking: 2026 Architecture Guide

Banks are modernizing core platforms at unprecedented speed. ISO 20022 migration deadlines, COBOL retirement pressure, BaaS competition, and fintechs operating at neobank scale are forcing legacy institutions to move. Digital transformation in banking 2026 requires a reference architecture that bridges microservices modernization, event-driven data pipelines, real-time AI/ML risk models, and regulatory guardrails — all while keeping legacy systems operational during the carve-out.

Architecture at a glance

Digital Transformation in Banking: 2026 Architecture Guide — diagram — Digital Transformation in Banking: 2026 Architecture Guide

This guide walks through the full stack: bounded-context domain models, event mesh topology, ISO 20022 coexistence patterns, open banking APIs, and strangler-fig migration strategies proven across tier-1 banks, challengers, and Asia-Pacific BaaS platforms. You’ll learn exactly what goes where, how to test dual-run scenarios, and how to cost-model the shift from monolithic COBOL to cloud-native fintech architecture.

What this post covers: reference architecture, ISO 20022 migration playbook, event-driven data backbone, AI/ML risk pipelines, open banking + FAPI 2.0, regulatory frameworks (DORA, OCC, RBI), strangler fig patterns, cost models, and case studies from real deployments.

Why Banking Digital Transformation Matters Now (2026)

The window to move has narrowed. SWIFT’s ISO 20022 migration deadline for MT (legacy SWIFT format) shutdown is November 2025 final day — a hard wall that forces banks to complete the MX (ISO 20022) transition or lose correspondent relationships. Meanwhile, mainframe COBOL systems that process trillions in daily payments are staffed by engineers with an average tenure exceeding 15 years; attrition is real and acceleration is non-negotiable.

Disruption from within adds pressure: neobanks like Revolut, Wise, N26, and Chime operate entirely on event-driven cloud-native stacks with 10x faster feature velocity. Traditional banks are losing deposits to their lower fees and frictionless onboarding. Banking-as-a-Service (BaaS) platforms — Solarisbank, Synapse, Treasury Prime — are capturing market share by offering white-label deposit and payments infrastructure, forcing retail and commercial banks to compete by embedding fintech-grade integrations.

Regulatory pressure compounds: the EU’s Digital Operational Resilience Act (DORA) mandates 4-hour RTO and 1-hour RPO; the US OCC has heightened standards for operational risk management; India’s RBI cyber framework tightens incident reporting. Open banking (PSD2/PSD3 in EU, Open Banking Standard in UK, etc.) forces third-party integrations. Non-compliance costs are material — fines, license suspension, customer exodus.

The answer is not a rip-and-replace monolith. It’s a strangler-fig pattern: routes new transaction flows through cloud-native microservices, coexists with legacy core through message translation, and gradually carves out bounded contexts (loans, deposits, payments) until the old system is hollowed out and retired.

Reference Architecture: The Banking Platform Stack (2026)

Layers of a Cloud-Native Banking Platform

Modern banking digital transformation rests on five tightly-coupled layers:

Channel Layer (Customer Facing): Web, mobile, embedded (PSD2 TPP), voice, ATM.
API Gateway + Orchestration: Routing, rate limiting, consent enforcement, PSD2/FAPI compliance.
Microservices Core (Bounded Contexts): Accounts (deposits, checking), Loans, Payments, Cards, Wealth, Settlements.
Event Mesh + Data Backbone: Kafka or Pulsar as the central nervous system. CDC (Change Data Capture) from each microservice pushes event streams to a real-time lakehouse.
Risk & Analytics Plane: Online fraud detection, AML screening, credit/lending decisioning, real-time regulatory reporting.

Each layer is cloud-native (Kubernetes, auto-scaling), stateless (no sticky sessions), and instrumented with observability (tracing, metrics, logs).

Architecture Diagram:

%%{init: {'theme':'neutral'}}%%
graph TB
    subgraph Channels
      Web["🌐 Web"]
      Mobile["📱 Mobile"]
      TPP["🔗 PSD2 TPP"]
      Voice["🎤 Voice API"]
    end

    subgraph APIGateway["API Gateway & Orchestration"]
      AuthN["OAuth2/OIDC<br/>AuthN"]
      Consent["Consent<br/>Engine"]
      RateLimit["Rate<br/>Limiting"]
      Router["Smart<br/>Router"]
    end

    subgraph MicroCore["Microservices Core (Bounded Contexts)"]
      Accounts["Accounts<br/>(Deposits, Checking)"]
      Loans["Loans<br/>(Origination, Servicing)"]
      Payments["Payments<br/>(ACH, Wire, RTP)"]
      Cards["Cards<br/>(Authorization, Settlement)"]
      Wealth["Wealth<br/>(Investments, Custody)"]
    end

    subgraph EventMesh["Event Mesh & Data Backbone"]
      Kafka["Kafka/Pulsar<br/>Event Stream"]
      CDC["CDC Layer<br/>(Change Data Capture)"]
      Lakehouse["Real-Time<br/>Lakehouse"]
    end

    subgraph RiskAI["Risk & AI/ML Plane"]
      Fraud["Fraud<br/>Detection"]
      AML["AML/Sanctions<br/>Screening"]
      Credit["Credit<br/>Decisioning"]
      RealTime["Real-Time<br/>Risk Reporting"]
    end

    Channels -->|RESTful, async| APIGateway
    APIGateway -->|Routed requests| MicroCore
    MicroCore -->|Domain Events| EventMesh
    CDC -->|Real-time streams| Lakehouse
    EventMesh -->|Events| RiskAI
    RiskAI -->|Risk signals| MicroCore
    Lakehouse -->|Feature store| RiskAI

Bounded Context: Microservices Organization

ISO 20022 migration forces context clarity. Each domain (Accounts, Loans, Payments) maps to a bounded context — a BIAN service domain. Payments, for example, publishes PaymentInitiated, PaymentValidated, PaymentSettled, and PaymentFailed events that other domains (fraud, AML, settlements) consume.

Key contexts for a tier-1 bank:

Accounts: Deposit accounts, current accounts, savings, interest calculation, statement generation. IBAN/BIC validation.
Loans: Loan origination, document collection, credit decisioning, servicing, payments, forbearance.
Payments: Payment schemes (ACH, SWIFT MX, RTP, real-time channels). Consensus settlement.
Cards: Card issuance, authorization, clearing, chargeback management.
Settlements: Nostro/vostro ledgers, forex settlement, liquidity management.
KYC/Compliance: Customer verification, sanctions screening (AML), ongoing monitoring.
FX & Treasury: Market data feeds, pricing, hedging, LIBOR-to-SOFR transition.

Each context owns its data pod — its own Postgres, YugabyteDB, or CockroachDB instance (distributed SQL for HA). No shared databases — this is the non-negotiable anti-pattern to avoid.

Event Mesh: Kafka or Pulsar?

The event mesh is the central nervous system. All microservices publish domain events, and all risk/analytics consumers subscribe.

Dimension	Kafka	Apache Pulsar
Tier-1 adoption	JPMorgan, Goldman, Bank of America	Stripe, Grab, Bytedance
Multi-tenancy	Namespace isolation, broker groups	Native, lightweight
Latency (p99)	~50ms	~10ms
Replication	Leader-follower	Geo-replication native
Operational burden	Higher (broker management, rebalancing)	Lower (automatic consensus)
Compliance scenarios	Well-trodden (regulatory audits)	Emerging (growing audit trail)

Recommendation: For legacy bank migration (lower risk tolerance), use Kafka + tiered storage. For greenfield BaaS (Solarisbank model), use Pulsar for lower latency and ops overhead. Dual-broker architectures (Kafka for legacy, Pulsar for new) are common during strangler-fig carve-outs.

All events are immutable, append-only, and logged per SR 11-7 (Model Risk Management) and DORA audit trails.

ISO 20022 Migration: Coexistence, Translation, Validation

ISO 20022 is a message definition language (XML, JSON, ASN.1 flavors) designed to carry richer metadata than legacy SWIFT MT formats. The message complexity is an order of magnitude higher: an MT103 (wire) has ~30 fields; an MX camt.050.001.09 (pain.001.001.03 for pacs) can have 200+ fields.

Migration Timeline and Deadlines

Nov 2025 (FINAL DEADLINE): SWIFT MT cutoff. All remaining MT traffic must cease.
2024–2025: Coexistence period. Most tier-1 banks and 80%+ of correspondent banks support both MT and MX.
2026 onward: MX-only. Legacy bridges must be fully decommissioned.

Coexistence Pattern: Bridge + Translator

During the migration window, banks run a dual-format translator sitting between the legacy core and SWIFT:

%%{init: {'theme':'neutral'}}%%
graph LR
    Legacy["Legacy Core<br/>(MT format, SWIFT FIN)"]
    Bridge["MT ↔ MX<br/>Translator Service"]
    SWIFT["SWIFT Network<br/>(MX or MT)"]
    NewCore["New Microservice<br/>(MX native)"]

    Legacy -->|MT messages| Bridge
    Bridge -->|Outbound: MX or MT| SWIFT
    SWIFT -->|Inbound: MX or MT| Bridge
    Bridge -->|MT for legacy<br/>MX for new| NewCore
    NewCore -->|MX events| Bridge
    Bridge -->|MT for legacy| Legacy

The translator service:
– Ingests MT messages (SWIFT FIN format) and MX (XML/JSON).
– Enriches with metadata (timestamps, originator, beneficiary, amount, scheme).
– Validates against regulatory rules (sanctions, limits, AML).
– Transforms into the target format (MT ↔ MX).
– Logs all translations for audit.
– Handles failure: if MX → MT loses data, the translator fails safe (rejects, not silently truncates).

Regression testing is mandatory. Run the same payment through both MT and MX paths, compare settlement outcomes. Any variance must be logged and investigated.

Data Backbone: CDC + Real-Time Lakehouse

Real-time risk and decisioning require fresh data, not batch jobs running nightly. CDC (Change Data Capture) from each microservice publishes events to Kafka; a stream processor (Kafka Streams, Flink, Spark Structured Streaming) aggregates into a feature store that feeds online ML models.

CDC Design

Each microservice (Accounts, Payments, Loans) runs a CDC connector:
– Postgres: logical replication + Debezium. Captures inserts, updates, deletes as JSON events.
– YugabyteDB / CockroachDB: native WAL tailing or Debezium.
– Legacy core (Oracle, DB2): Debezium connectors or custom extractors (GoldenGate is heavy; avoid if possible).

Events flow:

Microservice DB → Debezium → Kafka → Stream Processor → Feature Store (Redis/Feast) → Online inference

The feature store (e.g., Feast, Tecton, Hopsworks) materializes features (customer balance, transaction history, fraud score) into low-latency serving stores (Redis, DynamoDB). Online models query features with <50ms latency.

Real-Time Risk Decisioning: Fraud, AML, Credit

Fraud Detection Pipeline

%%{init: {'theme':'neutral'}}%%
graph TB
    subgraph Input
      TxnEvent["Transaction<br/>Event"]
      Customer["Customer<br/>Data"]
    end

    subgraph FeatureLayer
      FS["Feature Store<br/>(Feast/Tecton)"]
      History["Transaction<br/>History (7d, 30d, 90d)"]
      Device["Device<br/>Fingerprint"]
      Geo["GeoLocation"]
    end

    subgraph Inference
      OnlineModel["Online ML Model<br/>(Real-time XGBoost)"]
      RiskScore["Fraud Risk<br/>Score (0-100)"]
    end

    subgraph Action
      Decisioning["Decisioning Engine<br/>(rule-based)"]
      AuthZ["Authorization<br/>Response"]
      AlertTeam["Alert Fraud<br/>Team"]
    end

    TxnEvent -->|Query| FS
    Customer -->|Join| FS
    FS --> History & Device & Geo
    History & Device & Geo -->|Feature vector| OnlineModel
    OnlineModel --> RiskScore
    RiskScore -->|If > threshold| Decisioning
    Decisioning -->|Low risk: approve| AuthZ
    Decisioning -->|High risk: challenge| AlertTeam

Key metrics:
– Online latency: <100ms (else authorization timeout).
– False positive rate: <1% (else customer friction).
– Detection rate: >95% for known fraud patterns.

Models: Real-time XGBoost (fast inference), LightGBM, or neural nets (if latency budget allows). Retraining: daily, triggered by model drift (Population Stability Index > threshold).

AML/Sanctions Screening

Runs synchronously on payment initiation:
– OFAC lookup: Compare payer/payee names against US sanctions list (high confidence match = block).
– PEP screening: Politically Exposed Person databases (manually curated, lower precision).
– Transaction monitoring: Behavioral anomalies (circular flows, rapid consolidation, large round amounts).

Latency SLA: <500ms (acceptable for async payment schemes).

Credit Decisioning

Loan origination:
– Credit score: Pull from Equifax/Experian/TransUnion (or local equivalent: CIBIL in India).
– Custom model: Bank’s proprietary underwriting (income, debt-to-income, collateral, employment).
– Behavioral score: Days on customer, account activity, payment history.

Decision: approve, decline, manual review, ask for more docs.

Open Banking, PSD2, and FAPI 2.0

Open banking regulations (PSD2 in EU, Open Banking Standard in UK, RBI guidelines in India) mandate third-party access to customer accounts. This requires a Resource Server and Authorization Server built on modern OAuth2/OIDC standards.

FAPI 2.0 Architecture (Financial-Grade API)

%%{init: {'theme':'neutral'}}%%
graph TB
    subgraph TPP["Third-Party Provider<br/>(e.g., Fintech Aggregator)"]
      TPPApp["TPP App<br/>(Native/Web)"]
      TPPServer["TPP Backend"]
    end

    subgraph BankAuthz["Bank: Authorization"]
      AuthServer["Authorization Server<br/>(OAuth2/OIDC)"]
      ConsentUI["Consent UI<br/>(Account selection)"]
    end

    subgraph BankResource["Bank: Resource Server"]
      ResourceAPI["Resource API<br/>(Accounts, Transactions)"]
      AuthZGateway["OAuth2 Token<br/>Validation"]
    end

    subgraph CustomerDevice
      Customer["Customer<br/>(Mobile)"]
    end

    Customer -->|Opens TPP app| TPPApp
    TPPApp -->|auth_code flow| AuthServer
    AuthServer -->|Show scopes| ConsentUI
    Customer -->|Grants access| ConsentUI
    ConsentUI -->|Redirect w/ code| TPPServer
    TPPServer -->|Refresh token (if needed)| AuthServer
    TPPServer -->|Access token| ResourceAPI
    ResourceAPI -->|Validate| AuthZGateway
    AuthZGateway -->|Return accounts| TPPServer
    TPPServer -->|Display accounts| TPPApp

Key FAPI 2.0 rules:
– Mutual TLS (mTLS): All TPP-to-Bank traffic is encrypted; certificate pinning.
– Request object: All OAuth2 parameters signed in a JWT (prevents parameter tampering).
– PKCE: Proof Key for Code Exchange (prevents authorization code interception).
– IP whitelisting: Additional network-layer isolation.
– Rate limiting per TPP: Prevent scraping or abuse.

Consent lifecycle: Customer grants access for 90 days; auto-refresh requires re-consent. Revocation is one-click.

Regulatory Frameworks: DORA, OCC, RBI

DORA (Digital Operational Resilience Act — EU)

RTO (Recovery Time Objective): 4 hours for critical functions.
RPO (Recovery Point Objective): 1 hour (no more than 1 hour of data loss).

Mapping to architecture:
– Active-active Kubernetes clusters (multi-zone, multi-region).
– Event log durability: Kafka replication factor = 3, min.insync.replicas = 2.
– Database: Distributed SQL (YugabyteDB, CockroachDB) with 3-way replication.
– DNS failover: <1 minute.

Test: Chaos engineering. Kill a zone weekly. Verify RTO/RPO achieved.

OCC Heightened Standards (US)

Larger banks (>$100B assets) face enhanced operational risk scrutiny:
– Model risk governance (SR 11-7): every ML model requires validation, bias testing, explainability.
– Third-party risk management: TPP onboarding, SLA enforcement, incident response.
– Cybersecurity: incident reporting within 36 hours, vulnerability disclosure, pen testing.

RBI Cyber Framework (India)

Incident reporting: Reportable incidents within 6 hours, detailed timeline within 10 days.
Resilience: Business continuity drills quarterly.
Data residency: Customer data must remain in India (no cross-border flow without consent).

Strangler Fig: Gradual Carve-Out Strategy

Rip-and-replace is death. Instead, migrate one bounded context at a time while the legacy core continues running.

Migration Steps

Phase 1: Understand & Instrument
– Map legacy core to BIAN domains.
– Add distributed tracing (OpenTelemetry) to both legacy and new systems.
– Build CDC connectors.

Phase 2: Route New Traffic
– Deploy new microservice (e.g., Payments).
– Add a routing layer in the API Gateway that sends new payment initiation requests to the microservice.
– Route lookups (balance checks) to legacy core — new system is write-only initially.

Phase 3: Dual-Run Validation
– Send each new request through both the microservice and legacy core.
– Compare outcomes. Log deltas.
– Fix bugs. When delta = 0 for 2 weeks, proceed.

Phase 4: Read Switchover
– Gradually shift lookups to the new microservice. Monitor error rates.
– If error rate > threshold, rollback.

Phase 5: Retire Legacy
– Once new system handles 100% of traffic, put legacy core in read-only mode.
– Keep it online for 6 months as a safety net (archive/audit).
– Decommission.

Example: Payments context migration = 18–24 months (not 3 months). Plan accordingly.

Transformation Roadmap: 2026–2028

Phase	Timeline	Focus	Complexity
Phase 1: Foundation	Q2–Q3 2026	Event mesh (Kafka), CDC, API gateway, microservice skeleton	Medium
Phase 2: Payments	Q3 2026–Q1 2027	ACH, RTP, SWIFT MX migration, ISO 20022 translator	High
Phase 3: Accounts	Q1–Q3 2027	Deposits, checking, interest calc, statement gen. Move CDC to lakehouse.	High
Phase 4: Fraud/AML	Q2–Q4 2027	Real-time feature store, online ML models, sanctions screening	High
Phase 5: Loans	Q4 2027–Q2 2028	Origination, servicing, decisioning models. Link to credit bureau.	Very High
Phase 6: Legacy Retirement	Q2–Q4 2028	Decommission mainframe. Celebrate.	Low (but risky)

Parallel workstreams:
– Data governance & MDM (master data management).
– Observability & alerting.
– Security hardening (secrets management, mTLS, WAF rules).
– Compliance reporting (DORA, OCC, RBI).

Gotchas and What Goes Wrong

Forgetting the event log: If the event mesh is ephemeral (not durable), you lose audit trail. Kafka must be configured for durability: log.retention.hours = -1 (infinite), replication.factor = 3.
CDC lag explosion: Debezium can fall behind under high load. Monitor Kafka consumer lag. If lag > 5 minutes, alerts fire. Add consumer workers.
Dual-run comparison bugs: New system has subtly different rounding, locale handling, or timezone logic. Delta detection catches this. Don’t skip dual-run. One bank lost $50M because a rounding bug wasn’t caught.
ISO 20022 data loss: MT → MX translation truncates fields. Always validate that target format can express source data. If not, use enrichment fields or reject the translation.
Real-time model drift: Fraud models trained on 2024 data perform poorly on 2026 fraud patterns. Retrain daily. Monitor PSI (Population Stability Index). If PSI > 0.25, model is stale.
PSD2 scope creep: Regulators add new account types (business loans, payroll cards). Your OAuth2 scopes must evolve. Use a versioned scopes schema. Legacy TPPs get old scopes; new ones get extended scopes.
Kafka rebalancing outages: Adding brokers or topic partitions triggers rebalancing; in-flight messages may be lost if not idempotent. Ensure all consumers are idempotent. Idempotent API Design (see further reading) is non-negotiable.
Fallback to legacy under load: New microservice times out; traffic reverts to legacy core. Legacy core crashes under sudden spike. Load-test the fallback. Pre-warm legacy capacity.

Practical Recommendations

Before You Start

Audit the legacy core. Understand what it does, what it doesn’t. Map to BIAN domains. Find the bottlenecks (CPU, I/O, network).
Hire domain experts. Payments, loans, cards, settlements — each is a specialized domain. Budget for training.
Establish observability. Distributed tracing (Jaeger), metrics (Prometheus), logs (ELK) from day one. Don’t debug in production.

During Transformation

Start with a low-risk context. Not payments (too risky). Maybe reference data (rates, FX feeds) or analytics (reporting). Build confidence.
Invest in dual-run testing infrastructure. Automated delta detection. Make it part of CI/CD.
Establish a “transformation office.” Weekly sync across product, engineering, compliance, operations. Escalate blockers daily.
Version your schemas. Kafka schema registry (Confluent or Karapace). Every event has a version. Consumers declare what versions they support.

Checklist

[ ] Event mesh (Kafka/Pulsar) deployed, monitored, backed up.
[ ] CDC connectors running for all microservices. Consumer lag < 5 min.
[ ] API gateway routing rules tested for both happy path and failure scenarios.
[ ] Dual-run validator comparing new vs. legacy outcomes. Delta = 0 for ≥2 weeks.
[ ] Real-time feature store (Feast/Tecton) populated. Online inference latency <100ms.
[ ] Fraud, AML, credit decisioning models in A/B test. Metrics tracked (precision, recall, F1).
[ ] DORA RTO/RPO validated via chaos testing.
[ ] ISO 20022 translator regression tests passing.
[ ] PSD2 scopes and consent workflow tested with >3 TPP partners.
[ ] Incident response playbooks written. War-gamed quarterly.

FAQ

Q: How long does a full digital transformation take?
A: 24–36 months for a tier-1 bank (complex legacy, high risk). 12–18 months for a challenger or new entrant. Time is driven by regulatory review cycles and testing rigor, not engineering speed.

Q: Do we have to migrate to the cloud?
A: Not necessarily. Some banks keep the data center but modernize the software stack (legacy monolith → microservices on-prem). Cloud is faster, but on-prem is lower opex. Hybrid is common: cloud-native microservices, on-prem data for data residency compliance.

Q: How much will this cost?
A: Engineering + operations: $50M–$300M depending on bank size and legacy complexity. JPMorgan spent ~$1B (10 years, multi-pillar). Smaller regional banks: $20M–$50M over 3 years. Budget includes headcount, cloud infrastructure, tooling, and regulatory consulting.

Q: What happens to the COBOL engineers?
A: Retrain or retire. Many are near retirement anyway. Some become “legacy guardians” — maintaining the old core during the carve-out. Others learn cloud-native skills (Kubernetes, event streaming, Python/Go). Offer tuition reimbursement.

Q: Is Kafka or RabbitMQ better?
A: Kafka for tier-1 banks (event log durability, audit trails, replayability). RabbitMQ for smaller deployments. Pulsar if you need geo-replication and lower latency. No wrong answer if architecture is designed to support swapping.

Q: How do we handle PSD2 when we have legacy APIs?
A: Adapter pattern. Legacy APIs (SOAP, old REST) are wrapped in a PSD2-compliant gateway. OAuth2 scopes, mTLS, and consent logic sit on top. Clients (TPPs) see only the gateway, not the legacy API. It adds latency (<100ms) but ensures compliance.

Last Updated

April 29, 2026. Next refresh: October 2026 (when SWIFT migration completes and OCC fintech guidance evolves).

Author: Riju — fintech architect, 12+ years in banking systems. Worked on core modernization at JPMorgan and BaaS infrastructure at Treasury Prime.
Learn more about Riju.

Schema Markup

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Digital Transformation in Banking: 2026 Architecture Guide",
  "description": "Banking digital transformation in 2026 — core modernization, event streaming, ISO 20022, AI risk models, and a reference architecture for cloud-native fintech with regulatory guardrails.",
  "image": "/wp-content/uploads/2026/04/digital-transformation-banking-architecture-guide-2026-hero.jpg",
  "author": {"@type": "Person", "name": "Riju"},
  "publisher": {"@type": "Organization", "name": "iotdigitaltwinplm.com"},
  "datePublished": "2026-04-29T14:05:00+05:30",
  "dateModified": "2026-04-29T14:05:00+05:30",
  "mainEntityOfPage": "https://iotdigitaltwinplm.com/cloud-devops/digital-transformation-banking-architecture-guide-2026/",
  "proficiencyLevel": "Expert"
}

FAQ Schema

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How long does a full digital transformation take?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "24–36 months for a tier-1 bank. 12–18 months for a challenger. Timeline is driven by regulatory review and testing rigor, not engineering speed."
      }
    },
    {
      "@type": "Question",
      "name": "Do we have to migrate to the cloud?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Not necessarily. Some banks keep the data center but modernize the software stack. Cloud is faster; on-prem is lower opex. Hybrid is common."
      }
    },
    {
      "@type": "Question",
      "name": "How much will this cost?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Engineering + operations: $50M–$300M depending on bank size and legacy complexity. Smaller regional banks: $20M–$50M over 3 years."
      }
    },
    {
      "@type": "Question",
      "name": "What happens to the COBOL engineers?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Retrain or retire. Some become legacy guardians during carve-out. Others learn cloud-native skills. Offer tuition reimbursement."
      }
    },
    {
      "@type": "Question",
      "name": "Is Kafka or RabbitMQ better?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Kafka for tier-1 banks (event log durability, audit trails). RabbitMQ for smaller deployments. Pulsar if you need geo-replication and lower latency."
      }
    },
    {
      "@type": "Question",
      "name": "How do we handle PSD2 when we have legacy APIs?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Adapter pattern. Legacy APIs are wrapped in a PSD2-compliant gateway. OAuth2 scopes, mTLS, and consent logic sit on top. Clients see only the gateway."
      }
    }
  ]
}

Comments

Leave a Reply Cancel reply

Tag Cloud

Categories