← INSIGHTS·FIELD NOTESwave-2card-to-cardbank

Wave-2 for banks: card-to-card on Coreal ledger, without writing to T24.

Sequel to the Wave-1 KYC field note. How a tier-1 CEE universal bank shipped a card-to-card transfer product on the Coreal ledger in 45 days, with T24 as read-only book of record. Idempotency at the boundary, T+1 reconciliation, zero core writes.

I. Kovalenko

Head of Engineering · Coreal

23 May, 202611 min

After Wave-1

This is a sequel to the field note on Wave-1 in 90 days for a tier-1 CEE bank. That piece covered KYC orchestration — the bank's customer onboarding pipeline modernised from 5 days to 38 seconds, with T24 as read-only on the customer master.

Wave-2 starts in month 4 and runs through month 12. The first product we ship in Wave-2 is the one most banks ask for first: a card-to-card transfer product (internal, then external) running on the Coreal ledger. From the customer's point of view, the bank can now move money between cards in seconds, with full visibility in mobile banking. From the regulator's point of view, the bank ships a new payment product without changing the book of record. From the bank's point of view, the new product launch takes 45 days, not 9 months.

This field note describes the exact 45-day sequence we ran for an anonymous tier-1 CEE universal bank in 2025. The bank's core is Temenos T24 R20. The numbers and patterns generalise across T24 R18–R23; Mambu, Profile FibrCore and FIS Profile follow the same pattern with different specific surfaces.

The product, defined

The Wave-2 card-to-card product the bank ships has four user-facing variants:

Same-bank, same-customer: customer A moves money between their own two cards. Most common case (~40% of volume in our deployment).
Same-bank, different-customer: customer A sends money to customer B at the same bank. Real-time, no charge. (~30%)
External, EU SEPA: customer A sends money to a card or IBAN at a different EU bank. SEPA Instant where available, SEPA Credit Transfer otherwise. (~25%)
External, beyond EU: customer A sends money to a card outside EU. Currency conversion happens. (~5%)

All four are exposed in the bank's mobile app as a single "Transfer" action. The customer doesn't know they're crossing different rails. The bank's risk team gets a unified transaction-monitoring view.

The architecture

There are three boundaries to think about, and the architecture is defined by what crosses each one.

Boundary 1: T24 ↔ Coreal

This is the boundary we discussed in Wave-1. Read-only direction: T24 → Coreal (customer master, account state, balance snapshots). Write direction: Coreal → T24 (account-opening signal, end-of-day balance reconciliation entry). Wave-2 does not change this. The card-to-card product reads balances from T24 via the read-replica we set up in Wave-1, and reconciles at T+1.

Boundary 2: Coreal ↔ external rails

The new boundary in Wave-2. Coreal connects to:

The bank's existing card-issuing partner (Visa / Mastercard, the same one the bank uses on its primary debit card)
SEPA Instant gateway (via the bank's existing direct connection or via a PSP)
SEPA Credit Transfer
The bank's existing FX provider for the "beyond EU" case

In every case, Coreal is not issuing new cards in Wave-2 — it is using the bank's existing card-issuing relationship. The Visa BIN is the bank's. The Mastercard BIN is the bank's. We post a card-to-card transfer over the bank's existing acquiring contract as a normal scheme transaction.

Boundary 3: Coreal ↔ Coreal

Internal to Coreal: the ledger, the BPM workflow engine, the risk engine, the KYC orchestrator (from Wave-1), and the customer-state snapshot we keep in sync from T24.

The 45-day sequence

Days 1–7: Product scoping with the bank

A workshop sequence with the bank's product team, risk team, payment ops team and compliance. We're agreeing four things:

Which transfer types ship in Wave-2. (The four variants above — usually all four, but some banks defer "beyond EU" to Wave-3 if FX is contentious.)
Transaction limits. Daily / monthly / per-transaction limits per customer tier. Inherited from the bank's existing limit framework, not invented fresh.
Risk-rule integration. The bank's existing transaction-monitoring rules (from the AML programme) need to apply to card-to-card flows on the Coreal ledger. We agree the rule library and the escalation path to the bank's existing case-management system.
Customer-facing UX. The card-to-card flow inside the bank's mobile app. Most banks ship this as a refactor of their existing internal-transfer flow.

Output: a one-page spec the bank's product, risk, ops and compliance all signed off on.

Days 8–18: Scheme connectivity and risk rules

Two streams running in parallel.

Stream 1 — Card scheme connectivity. Coreal connects to the bank's existing card-issuing partner. The bank's existing BIN range. The bank's existing acquiring contract. We do not create a new scheme relationship — we plug into the bank's existing one. Typical timeline: 8–12 days, mostly waiting for the scheme partner to configure us as a permitted MID under the bank's contract.

Stream 2 — Risk rules. The bank's transaction-monitoring rules from its AML platform get translated into Coreal-side risk-rule definitions. Most banks have 200–400 rules. The active ones — say, the top 60 by hit rate — get migrated first. The long-tail (false-positive heavy, rare-event rules) gets migrated in a second pass. Decision journal entries from Coreal feed back to the bank's case-management system for review. Average case median time: 12 minutes (close to telco-side field note numbers).

Days 18–32: Build

The actual product build is shorter than most banks expect because the components are pre-built.

The Coreal ledger handles a card-to-card transfer in the same way as any other transfer: double-entry posting, idempotency key at the boundary, status state machine, retry-safe.

The Minctrl pipeline ships:

Mobile-app UI integration code (works against the bank's existing mobile app SDK)
Risk engine call hooks
Scheme acquirer message generators (ISO 20022 / ISO 8583 as appropriate)
SEPA Instant / SCT participant message generators
Reconciliation rules T24 ↔ Coreal at T+1
Operations dashboard for the bank's payment ops team

Total person-time for the build: 280 hours (Coreal) + 120 hours (bank-side: mobile UI integration, risk-rule sign-off, ops dashboard review).

Days 32–40: Soft launch

Days 32–35: 50 bank-staff applications. The bank's own staff use the new transfer flow. Bugs found in this phase: 11 (mostly UX, 2 ledger-edge cases). All fixed within 48 hours.

Days 35–40: 5,000 customer applications, invitation-only from a low-risk segment (existing primary-card holders who already use internal transfers). The transfer flow is gated by a feature flag in the bank's app. Customers see a banner: "Try our new instant transfer." Conversion rate to first transfer: 22%. Drop-off rate from intent to completion: 4%. Median time-to-completion: 16 seconds.

Reconciliation drift between Coreal and T24 during soft launch: zero. T24 read-replica latency: 800ms p95. Coreal-side posting latency: 28ms p95.

Days 40–45: Public launch

Public launch gates on three things:

Reconciliation clean for 96 hours. Zero drift, every transaction posted to T24 on T+1, no manual fix-ups.
Risk-team comfort. The risk team reviews the case escalation flow for the 5,000 soft-launch transactions and signs off that the case management is working.
Compliance review. The compliance team confirms that the AML monitoring rules are firing as expected, with false-positive rate ≤ 4% (the bank's internal target).

All three pass. Public launch on day 45.

What ships, what doesn't

What ships in Wave-2 (45 days)

Card-to-card transfer, all four variants
Mobile-app UX (composite from bank's app + Coreal-rendered confirmation flow)
Risk-rule integration with existing AML platform
T+1 reconciliation T24 ↔ Coreal (zero drift)
Operations dashboard for payment ops team
Decision journal for every transfer (DORA-aligned, replayable)

What does NOT ship in Wave-2

Card issuance (the bank uses its existing BIN; new BIN issuance is Wave-3)
IBAN issuance from Coreal (Wave-3)
FX margin capture (the bank's existing FX provider continues to set the rate; Coreal-margin FX is Wave-3)
Crypto-buy (separate Wave-2 product if the bank wants it, but a separate engagement)

What does NOT change in Wave-2

The bank's licence — same as Wave-1
The bank's banking app brand — same logo, same UX framework
The bank's customer support team — same team handles disputes, escalations
T24 customer master — read-only, never written from Coreal in Wave-2 (only on initial account open at Wave-1, same pattern)
The bank's risk and AML programmes — Coreal applies the bank's existing rule library, not a new one

The reconciliation pattern

This is the part most banks ask about and most providers leave fuzzy. Here is exactly how Coreal and T24 stay in sync during Wave-2.

On every card-to-card transfer that touches an existing T24 account:

T+0 (real-time):
  1. Customer initiates transfer in mobile app
  2. Coreal validates balance via T24 read-replica
  3. Coreal posts double-entry on its own ledger (sub-second)
  4. Coreal sends scheme/SEPA message via acquirer
  5. Coreal returns confirmation to customer
  6. Customer sees transfer complete

T+1 (overnight reconciliation):
  7. Coreal compiles end-of-day delta per T24 account
  8. Coreal posts a single net entry to T24 via existing API
  9. T24 reconciliation job confirms net entry matches Coreal's day total
  10. Reconciliation report goes to bank's payment ops team

If step 8 fails (T24 is down, API returns error), the entry is retried with exponential backoff. If retries exhaust, the entry is queued for manual review. In practice, this happens approximately once per 18 months for a tier-1 bank — almost always due to scheduled T24 maintenance windows that the bank's team forgets to whitelist.

The customer never sees this. From their point of view the transfer was instant. The reconciliation happens behind the scenes on an SLA the bank's ops team monitors.

What broke (the honest list)

In the deployment described, three things broke that I think are worth documenting:

1. T24 read-replica stale during scheme settlement. On day 36 of soft launch we had three transfers fail because the T24 read-replica was behind real-time T24 by 4 seconds, and the customer attempted a second transfer using the balance the read-replica still showed. The customer's first transfer had cleared but the read-replica hadn't caught up. Fix: cache invalidation on Coreal-side after every posted transfer to that customer. Implemented in 4 hours. Not seen again.

2. SEPA Instant rejection for valid transfers. On day 39 we had a batch of SEPA Instant transfers rejected by the bank's existing SEPA Instant gateway because the message ID format didn't match exactly what the gateway expected. The bank's existing internal transfer system used a different ID convention. Fix: adopt the bank's existing convention. 2 hours of work. Annoying but not surprising.

3. The bank's risk team needed visibility we hadn't built. On day 42 the risk team said the case-management feed from Coreal was missing two fields they used in their internal dashboard. The two fields were not part of any standard data flow we'd seen at other banks. The fields were valuable for the bank's analysts. We added them in 6 hours. The fix had to ship a day before public launch.

The pattern: things broke not in the new system but at the boundary with existing systems. This is the universal lesson of bank engineering. The product can be perfect; the boundary still surprises you.

What the numbers were

In the 90 days after public launch, the bank's card-to-card transfer product:

Processed 2.4M transactions (across all four variants)
Had a reconciliation drift of 0.00 cents — zero, every day, every account
Hit a 99.95% scheme-success rate (better than the bank's existing inter-bank transfer rate)
Generated a fee revenue uplift of approximately €600k over the 90-day window (the bank introduced a small fee for the non-SEPA-Instant external transfers; same-bank transfers were free)
Reduced support-ticket volume on transfers by 18% (because the new flow's confirmation UX was clearer than the legacy one)

The bank's ROI on Wave-2 was not measured in fee revenue alone. The strategic outcome was that the bank now had a path to ship new payment products on Coreal ledger without further migration risk to T24. The next products in the queue — instant credit, crypto-buy, FX, lending — all ride on the same Coreal foundation.

What Wave-3 looks like from here

Wave-3 (months 12–36) is where the architectural picture changes. By month 12 the bank has Wave-1 (KYC) and Wave-2 (card-to-card + first additional products) running on Coreal. New customer onboardings now open accounts on Coreal directly — the legacy T24 customer master is only consulted for existing customers, not new ones. By month 24, the new-product transaction volume on Coreal equals the legacy on T24. By month 36, Coreal-handled volume is the majority of transactional volume for the bank's retail business.

Crucially, this never required a cutover. There is no day-zero migration. The legacy core demotes itself by attrition as the new flows grow.

We wrote about this strategic shape in Adjacent vs replacement: why bank-core projects fail at month 18. This Wave-2 field note is the engineering proof: the architecture works in production at month 4 already.

Field note reflects our direct delivery experience at a tier-1 CEE universal bank on Temenos T24 R20. Specifics generalise across T24 R18–R23; Mambu, Profile FibrCore and FIS Profile follow the same pattern with different surfaces and timelines. For a Wave-2 brief scoped to your specific core platform, book a working session →

RELATED · BY TOPIC

FIELD NOTES