Twelve vendors pitched. None of them asked to see your current process maps.
That gap tells you something useful. Core-banking RFPs routinely run to hundreds of pages. They specify API standards, data residency requirements, SLA uptime tiers, integration protocols, and security certification matrices. They do not ask the one question that determines whether the new system will perform differently from the old one: are your processes ready for it?
A core-banking replacement is, at its root, a confession. Process debt compounded past the system layer. The platform that once worked is now carrying a decade of workarounds, compensating controls, and approval gates that exist because nobody ever revisited the original design. The question is not whether the new core is better. The question is whether it will inherit the same dysfunction.
What a Core-Banking RFP Is Actually Signalling
When a COO or CTO office in Singapore or Malaysia opens a core-banking selection project, the vendor community reads it as a technology decision. It is not. It is a process decision that reached the point where a system change appeared easier than fixing the underlying workflow.
A recent core-banking vendor's agentic-core launch (2026) signalled where the market is heading: processing logic that adapts dynamically, with reduced batch-window dependency and decisioning pushed closer to the transaction layer. That is a meaningful technical direction. But an agentic core does not repair a broken underwriting referral loop. It does not resolve a dual-entry problem that exists because two departments never agreed on data ownership. It does not eliminate approval gates that exist as risk theatre rather than risk management.
A better core runs broken processes faster. That is not an improvement — it is an acceleration of the problem. Process readiness must come before vendor readiness. If it does not, the RFP scores capabilities against a process state that should not survive into the new system.
Why the Sequence Matters
Consider a mid-tier bank preparing for core modernisation. The stated drivers are settlement latency, reconciliation exceptions, and a loan origination workflow requiring manual intervention at seven points. These are framed as system limitations in every stakeholder briefing.
Map the workflows. Classify each step. The settlement latency is driven by a confirmation handoff that runs through three teams, none of whom owns the SLA. The reconciliation exceptions originate from a data-capture step that was added as an audit compensating control, never reviewed, and now feeds a queue nobody clears. The loan origination interventions exist because approval criteria were never written into the process — they live in the heads of four relationship managers.
None of these are system problems. All of them will migrate to the new core unless the process is designed before the system is selected.
As Abdulla Al-Awadi, Chief Strategy Officer and founder of ESSAM, has noted: 'The new core is only as good as the process you feed it. Buy the platform last.'
By analogy: a Kuwait bank reduced a procurement cycle from 139 days to 57 days. That is a 59% reduction, 82 days of work retired, and a 106.9% efficiency improvement, all with the same headcount. The gain came from completing the Eliminate and Simplify phases before changing any system. The system change came last. That sequencing principle holds across any process-layer modernisation, including core banking.
The 12-Point Process-Readiness Checklist
Use this checklist before issuing or scoring a core-banking RFP. Each criterion should be answerable with documented evidence — not team knowledge, not verbal assurance.
| # | Readiness criterion | Evidence required | Score (0-2) |
|---|---|---|---|
| 1 | All in-scope processes are baselined in current-state documentation | Process maps or session transcripts | |
| 2 | Each process step has a defined owner (RACI complete per process) | RACI matrix | |
| 3 | Waste has been categorised per step: duplication, waiting, over-processing | Waste-tag report | |
| 4 | Approval gates have written decision criteria, not tacit knowledge | Decision rules document | |
| 5 | Data-capture steps have a named downstream consumer for each field | Data lineage record | |
| 6 | Handoff points have defined, measurable SLAs | SLA register | |
| 7 | Compensating controls are dated, risk-reviewed, and still live | Control log with review dates | |
| 8 | Exception paths are mapped, not only the happy path | Exception flow documentation | |
| 9 | Process owners have signed off on the to-be design | Approval record | |
| 10 | Automation candidates are post-Eliminate and post-Simplify in the design sequence | Design sequence record | |
| 11 | SOP distribution channel and adoption method are confirmed for post-go-live | Deployment plan | |
| 12 | Baseline cycle time and error rate are recorded as a pre-project reference | Pre-project metrics log |
Scoring guide: 2 = documented evidence in hand; 1 = in progress with a named owner; 0 = not started. A total score below 16 out of 24 indicates material process risk that a new core system will not resolve. Document the gap before opening the RFP.
What Vendor Responses Reveal
Ask each shortlisted vendor to review this checklist before their first presentation. Their response is more informative than any feature matrix.
Vendors whose platform assumes process maturity — and most do — will not have an answer for criteria 1 through 5. They will propose to handle those items during 'implementation workshops.' That is not a delivery commitment; that is a risk transfer. The process-design work is being delegated to a phase where it competes with integration timelines and go-live pressure.
Look for vendors who require a baseline process audit before system configuration begins. Look for implementation programmes that include SOP generation, RACI assignment, and SLA definition as deliverables — not optional workstreams. Look for post-go-live deployment pathways that do not require staff to learn a new application to access approved operating standards.
If a vendor's proposal jumps directly to data migration and integration testing, the process layer is being assumed rather than assessed. That assumption is where post-go-live incidents originate, and where the most expensive post-implementation consultancy work is eventually billed.
Running Process Readiness Before the RFP Closes
The E-S-S-A-M framework — Eliminate, Simplify and Standardise, Automate, Migrate — positions the Migrate phase as the last action, not the first. Migration into a new core is appropriate after the preceding phases are complete. Selecting a core before completing Eliminate and Simplify is not modernisation; it is migration of unreviewed debt.
ESSAM runs the full baseline, waste classification, and to-be design in a single conversational session per process. No notation software. No preparation workshops. The process owner describes the current workflow. ESSAM maps each step, auto-tags waste type, identifies elimination candidates, and generates a before/after audit view with populated SOP drafts, RACI assignments, and SLA definitions.
In Singapore and Malaysia, approved standards are deployed over WhatsApp — near-universal adoption, no new application required, no training overhead before the first process runs correctly.
The output of that session is a completed process-readiness checklist, ready before the first vendor briefing. That is the right order. Evaluate process readiness first, then evaluate vendors against it.
If your bank is entering a core-banking selection process, start with the checklist. The vendors can wait.
Book a demo on your process. Your actual workflow. No hypothetical use case required.
Related reading: Process Improvement RFP Template · Banking Process Improvement Software · COO Process Priorities in Banking