Your payments outgrew the core. Move FLEXCUBE FT and PC to Oracle Banking Payments.
FT and PC still run in FLEXCUBE 12.x and 14.x. Cross-border is ISO 20022 only, instant schemes run around the clock, and Oracle ships scheme changes in OBPM releases. We move your flows by waves and keep FLEXCUBE as the system of record.
- From
- FT and PC in FLEXCUBE 12.x or 14.x
- To
- Oracle Banking Payments 14.x
- Messaging
- SWIFT MT to ISO 20022 MX / CBPR+
FT and PC still work. That is the problem.
FT and PC ship with FLEXCUBE 12.x and 14.x, so an upgrade does not force the move, and many banks keep payments inside the core. Over the years channels, sanctions screening, charges, local clearing rules and EOD jobs were built around those two modules.
Meanwhile the payment world changed its rules. SWIFT stopped carrying MT payment instructions between banks on 22 November 2025. Instant schemes run 24/7, while a core still closes its day. Every new rulebook version becomes another custom change inside the core, and every custom change is one more line in the next upgrade.
Oracle Banking Payments is Oracle's answer to that: a separate payments hub, pre-integrated with FLEXCUBE, built on ISO 20022, ready for 24/7 schemes and updated with each scheme change. Getting there is a migration with its own inventory, rehearsals and cutover, not a module swap.
Six reasons payments leave the core
- 01Since 22 Nov 2025Cross-border is ISO 20022 onlySWIFT now carries payment instructions between banks (MT103, MT202, MT205 COV) only as ISO 20022 messages. Its translation for MT receivers is a contingency, not a route to build on. OBPM processes CBPR+ messages natively.
- 0224/7/365Instant schemes never closeSEPA Instant and the domestic instant systems built like it run around the clock. FT and PC live inside the core’s business day and its EOD. OBPM is built for 24/7 schemes.
- 03RulebooksScheme changes arrive as Oracle releasesCBPR+, SEPA Instant, RTGS ISO formats and Verification of Payee appear in OBPM release notes. Kept in FT and PC, the same changes tend to become custom work the bank builds, tests and carries.
- 04UpgradesLighter core upgradesPayment customizations in the core land in every upgrade’s customization register. Moved to OBPM, they leave the core, and payments are upgraded on their own schedule.
- 05OperationsOne payment, one placeWhen the legs of a payment sit in several systems, nobody sees it whole. OBPM gives operations queues for repair, sanctions and investigations, dashboards and a full audit trail.
- 06Open APIsChannels plug in onceChannels and partners connect to OBPM through REST and JSON APIs instead of point-to-point links into the core, and one hub can serve more than one core or deposit system.
Deadlines that do not wait for the next core upgrade
- 9 Oct 2025Euro area · in forceBanks must send SEPA Instant and offer Verification of Payee
- 22 Nov 2025SWIFT · in forceMT payment instructions retired for cross-border; CBPR+ only
- Nov 2026SWIFT · aheadPayment messages need structured or hybrid addresses
- 9 Jan 2027EU outside the euro area · aheadBanks must receive SEPA Instant
- 9 Jul 2027EU outside the euro area · aheadBanks must send SEPA Instant and offer Verification of Payee
Dates from SWIFT’s CBPR+ programme and the EU Instant Payments Regulation. Which of them apply depends on where the bank operates and the schemes it uses.
Payments in FT and PC versus Oracle Banking Payments
| Topic | Payments in FT and PC | Oracle Banking Payments |
|---|---|---|
| Scheme updates | Custom changes the bank builds and carries | Delivered in Oracle releases |
| Operating hours | Bound to the core’s business day and EOD | Built for 24/7 schemes |
| Visibility | Payment legs spread across several systems | One record per payment, queues and dashboards |
| Upgrade impact | Payment customizations in every core upgrade | Payments upgraded on their own schedule |
| Channels | Point-to-point links into the core | REST and JSON APIs |
| Reach | One FLEXCUBE instance | One hub for several cores or deposit systems |
Based on Oracle’s positioning of OBPM against payments processed in the core, and the OBPM 14.8 release notes.
Payments leave the core. Accounts stay.
Four kinds of change
Never every flow on one night
Payments move by waves, so the bank never switches every flow on one night.
Example order. Each wave has its own rollback; FT and PC keep processing the flows of later waves until their turn.
How we run the migration
- 01Payment inventoryEvery flow by type, network, channel, volume and cut-off. Every FT and PC customization and interface. Every EOD job that touches payments.
- 02Target designOBPM products and networks, routing, the accounting handoff to FLEXCUBE, screening, status back to the channels. A decision per flow: migrate, rebuild or retire.
- 03Build and integrateOBPM configuration, ISO 20022 mapping, channel and gateway adapters, reconciliation.
- 04Migrate and rehearseStatic data is migrated: standing instructions, templates, directories. Each flow runs in parallel, and mock cutovers include in-flight and future-dated items. Every rehearsal is reconciled on counts, amounts, nostro and GL.
- 05Cut over by waveFlows move in waves, for example internal transfers first, then domestic, then cross-border, each with its own rollback. Hypercare follows, then support by the same team.
Every rehearsal is reconciled
A wave goes live only when its last rehearsal passes all five checks.
- Payment counts by flow and status
- Amounts by currency
- Nostro and settlement accounts
- GL control accounts after EOD
- In-flight and future-dated items accounted for
When it's time to move
- Cross-border flows still leave FT as MT and depend on translation.
- Your bank has to send and receive SEPA Instant with Verification of Payee, or your local scheme is moving to ISO 20022.
- A FLEXCUBE upgrade is planned and payment customizations fill its register.
- FT and PC customizations for local clearing keep growing.
- Operations repair payments by hand because status tracking is weak.
- You need instant payments around the clock, and the core's EOD stops the payment flow.
What the bank gets
- A payment flow inventory with a decision for every flow
- An interface map: what pointed at FT and PC and where it points now
- Migration rules for in-flight and future-dated payments
- A reconciliation pack for every rehearsal
- A cutover runbook per wave with rollback criteria
Frequently asked questions
More FLEXCUBE services
Start with the payment inventory.
A fixed-scope assessment lists every payment flow, interface and customization on FT and PC, and gives you the wave plan and an estimate.