Roughly 80% of failed banking technology projects trace back to one root cause: poor vendor evaluation at the RFP stage, not the technology itself. This template is for banks, NBFCs, and fintechs preparing to run a core banking RFP process, whether replacing a legacy core or launching a new digital-first product.
Before You Start
- [ ] Define regulatory and architectural constraints first — data residency rules, DORA/RBI/local regulator requirements, and TPRM (third-party risk management) obligations — before writing a single RFP question
- [ ] Decide whether this is a full core replacement or a parallel/hybrid rollout, since the RFP questions differ significantly
- [ ] Identify every downstream system the core must integrate with: payments rails, KYC/AML tooling, card issuing, general ledger, and reporting/regulatory feeds
- [ ] Set a realistic migration rehearsal requirement — vendors should demonstrate a rollback plan, not just a go-live plan
Section 1: Company and Product Background
- [ ] Years in production with institutions of comparable size and transaction volume
- [ ] Reference clients running your specific regulatory regime (not just "global" references)
- [ ] Ownership and financial stability of the vendor (relevant for multi-year contracts)
Section 2: Technical and Architecture Requirements
- [ ] Evidence-backed processing reliability at your target transaction complexity and volume — ask for load-test results, not marketing claims
- [ ] API-first architecture with documented, versioned APIs for every core function (accounts, ledger, payments)
- [ ] Demonstrated product agility: can business users adjust parameters (interest rates, fee schedules) without a vendor change request?
- [ ] Data residency options matching your regulatory jurisdiction
Section 3: Security and Compliance
- [ ] SOC 2 Type II or equivalent certification, current within 12 months
- [ ] PCI-DSS compliance scope if the core touches card data directly or indirectly
- [ ] KYC/AML integration support — native or via documented API to third-party providers
- [ ] Named data protection officer or equivalent compliance contact
Section 4: SLAs and Support
- [ ] Uptime SLA with a specific number (99.9% vs 99.99% is a real difference at scale), not "high availability"
- [ ] Severity definitions and response-time commitments per severity level
- [ ] Financial remedies or credits when SLAs are missed, in writing
- [ ] Named implementation and post-launch support contacts, not a generic ticket queue
Vendor Scorecard
| Criterion | Weight | Score (1–5) | Notes |
|---|---|---|---|
| Migration plan realism (rehearsal, rollback) | 25% | Ask for a dry-run demo, not a slide | |
| Regulatory and compliance fit | 25% | Confirm certifications are current, not expired | |
| API architecture and integration depth | 20% | Test the sandbox yourself before scoring | |
| SLA strength and remedies | 15% | Get specific numbers and penalty clauses in writing | |
| Total cost of ownership (5-year) | 15% | Include integration, per-transaction fees, and support tiers |
Red Flags to Watch For
- Vendors who can't produce a migration rehearsal plan with measurable rollback criteria
- Compliance certifications that are expired or "in progress"
- SLA language using vague terms like "commercially reasonable efforts" instead of specific percentages
- No sandbox environment available for your team to test the API before signing
How to Use This Template
Send this to three to five shortlisted vendors as a structured RFP, and require written answers to every checklist item — not a generic capability deck. Score responses against the weighted scorecard using the same evaluators for every vendor, and require a live sandbox demonstration before any contract signature. Build in a formal architecture review with your own engineering and compliance teams before final selection, not after.