Architecture
Logical model, deployment shapes, integration surface and security boundary, with diagrams. See /architecture and the API detail in the Developer Center.
Six evaluation domains, each as a table of questions you can lift directly into an RFP: architecture and data model, AI and automation controls, security and compliance, integration and coexistence, exit and reversibility, operations and TCO. The questions are vendor-neutral and apply to any platform you are evaluating. After each table, CoreFi answers as the worked example, with links to the pages where the full detail lives. Written for the CIO, CTO or procurement lead who has to turn a shortlist into a defensible decision; the executive framing is on CoreFi for CIOs.
Six evaluation domains, three coexistence patterns instead of a big-bang cutover, and the reversibility test at each phase boundary: the method behind this checklist, narrated before you lift it into an RFP.
Each table has three columns: the question to put to the vendor, why the answer matters, and what a good answer looks like. To use it in procurement: copy the question column into your RFP, require written answers, and score each response against the third column. Treat any answer that cannot be put in writing, demonstrated in a sandbox, or referenced to documentation as a gap, not a maybe. Where vendor archetypes differ structurally, the category-level comparison on How CoreFi Compares explains which questions apply to which kind of platform.
The data model outlives every other decision on this page. These questions establish whether the ledger, the API surface and the tenancy model can carry your products without a fork.
| Evaluation question | Why it matters | What good looks like |
|---|---|---|
| Is the ledger real-time and double-entry, with no batch posting window? | Batch cores constrain product design, reconciliation and customer experience for the life of the contract. | Real-time posting with standard double-entry semantics; balances queryable at any moment, not after end-of-day. |
| What share of platform functionality is reachable through documented APIs? | Anything not on the API surface becomes a paid change request or a manual process later. | Versioned, documented APIs across core, lending and onboarding surfaces, with sandbox access before contract signature. |
| What is the multi-tenancy posture, and what isolation does each deployment shape provide? | Tenancy determines blast radius, residency options, upgrade control and what your auditor will ask about. | Named deployment shapes with the isolation boundary of each stated in writing, not a single answer for all customers. |
| How is the data model extended without forking the product? | Custom forks decay into unsupported versions that cannot take vendor upgrades. | Custom fields, products and workflows delivered through configuration and documented extension points, not vendor code changes. |
CoreFi as the worked example. A real-time double-entry core with no proprietary data formats, a headless API surface documented in the Developer Center, and the three deployment shapes above, described in full on the architecture page.
If the platform puts AI agents anywhere near the ledger, the evaluation question is not model quality. It is what stands between the model and a side effect.
| Evaluation question | Why it matters | What good looks like |
|---|---|---|
| What sits between a model's output and a side effect on the ledger? | A model with direct write access is an unsupervised operator; your risk framework has no category for that. | Policy gates evaluated before any API call: role permissions, transaction limits, consent and sanctions checks. Failed checks stop the workflow. |
| Who sets human-approval thresholds, and how are changes recorded? | Accountability for monetary and credit decisions has to stay with the institution, not the vendor or the model. | Thresholds owned by the institution as configuration, with a change history; monetary actions routable to human approval by default. |
| What does the audit record capture when an agent participated in a workflow? | Supervisors and internal audit will ask which model saw which data and proposed which action. | One append-only record per case: model identifier, context, proposed plan, policy decision, human approvals and final state. |
| Is the control plane tied to one model vendor? | Model markets move faster than core banking contracts; controls bound to one provider become a second lock-in. | Model-agnostic controls: the policy gates, approvals and audit record do not change when the underlying model is swapped. |
CoreFi as the worked example. CoreFi treats every agent like any other operator: scoped tokens, policy gates before any side effect, configurable approval shapes and a case-level audit record, on ChatGPT, Claude, Gemini or the institution's own hosted models. The control surfaces are documented on Security & Compliance.
Separate what the vendor holds from what the vendor claims. The useful evaluation artifact is a written status per control, not a logo wall.
| Evaluation question | Why it matters | What good looks like |
|---|---|---|
| What is encrypted in transit and at rest, and who can hold the keys? | Encryption posture is the baseline question every security review and supervisor starts with. | TLS in transit, encryption at rest across tenant data, documents and audit log; institution-managed keys where the deployment shape requires it. |
| Do humans, API consumers and AI agents pass through the same access-control layer? | Parallel permission systems drift apart; the gap between them is where incidents happen. | One role-based access layer for every actor, scoped tokens per identity, SSO and MFA for operators, step-up authentication for privileged actions. |
| How are GDPR obligations supported: lawful basis, data-subject rights, sub-processors, residency? | The institution stays data controller; the platform has to make that accountability workable, not absorb it. | A standard DPA, a structured data-subject-rights workflow, a published sub-processor list and a stated data-residency boundary per deployment. |
| Which certifications are held today, which are in progress, and what evidence is available? | "Aligned with" and "certified" are different facts; procurement needs the exact one in writing. | An explicit status per attestation: held, in progress or not held, with evidence available under NDA and no claim beyond the documented status. |
CoreFi as the worked example. CoreFi publishes its control surfaces and certification status in exactly this format on Security & Compliance: ISO 27001 and SOC 2 Type II are reported as in progress, not claimed as held, with evidence available on request to buyers under NDA. The sub-processor list, DPA and supporting artefacts are tracked through the Trust Center.
Almost no institution replaces its core on day one. The evaluation question is whether the platform can run alongside what you already operate, with data flowing both ways under audit.
| Evaluation question | Why it matters | What good looks like |
|---|---|---|
| Can the platform run alongside the legacy core and write back to it where it remains system of record? | A big-bang cutover is the programme risk most boards and auditors will no longer sign. | API, file-feed and event-stream integration patterns, with the legacy core staying system of record for any scope not yet migrated, and no direct database access required. |
| What event streams do downstream systems get? | Analytics, regulatory reporting and the data warehouse need state changes pushed to them, not polled. | Outbound business events per topic, from a durable log that consumers can replay after an outage. |
| How do partner systems such as KYC providers, payment rails and scoring engines integrate? | Every connection is a cost line and a failure mode; the mechanics decide both. | Signed webhooks with documented retry, signature-verification and idempotency behaviour, inheriting the same identity and audit model as the APIs. |
| What is the reference shape for a first bounded journey? | A first journey proves the integration pattern before the institution commits the estate. | A named first-journey scope with a defined coexistence window, a stated timeline and reversibility at the end of each phase. |
CoreFi as the worked example. CoreFi's integration surface spans REST APIs, event streams, webhooks, file imports and SDKs, mapped on the architecture page and specified in the Developer Center. The standard first journey goes live in 8–14 weeks, writing back to the legacy core while the rest of the bank stays where it is.
Exit terms are cheapest to negotiate before signature and most expensive to discover at renewal. Ask these questions while you still have alternatives on the table.
| Evaluation question | Why it matters | What good looks like |
|---|---|---|
| Can all tenant data be exported in documented, non-proprietary formats? | Exit cost is the largest hidden TCO line, and proprietary formats are how it hides. | Full export of accounts, transactions, documents and audit records through documented APIs or standard formats, testable before signature. |
| Are the APIs documented completely enough to rebuild integrations on another platform? | Lock-in by friction is still lock-in: undocumented surfaces make leaving impractical even when contracts allow it. | A public or contractually guaranteed API reference and sandbox, so a successor integration can be scoped without vendor cooperation. |
| What exit assistance, timeline and pricing does the contract commit to? | Exit posture decides your leverage at every renewal for the life of the relationship. | A defined exit posture in the contract: transition-assistance obligations, a stated timeline and exit pricing agreed before signature. |
| What happens to data, backups and keys at termination? | Regulators and your DPO will ask for the deletion-and-return commitments in writing. | Return and deletion commitments in the DPA, covering backups and the audit log, with confirmation deliverables named. |
CoreFi as the worked example. CoreFi uses no proprietary data formats; tenant data is exportable through the documented APIs, and every adoption path on For CIOs is described with its coexistence window and exit posture rather than a one-way commitment.
Platform fees are the visible cost line. The five-year total is decided by SLOs, observability, integration spend, upgrade mechanics and the exit terms from the previous domain.
| Evaluation question | Why it matters | What good looks like |
|---|---|---|
| Which SLOs are contractual, and what is the measured performance against them? | A marketing uptime figure and a contractual SLO with remedies are different commitments. | SLOs in the contract with remedies attached, plus measured historical performance the vendor will put in writing. |
| What observability does the institution's own team get? | Second-line oversight and incident response need your team looking at live signals, not waiting on vendor tickets. | Structured logs, audit export, an operations console and SLO visibility available to the institution, not only to the vendor. |
| Which cost lines exist beyond the platform fee, over five years? | Integration, per-transaction charges, compliance work and exit costs routinely dominate the licence fee. | A full five-year view across licence, integration, operations, compliance and exit, with the pricing model's scaling behaviour stated. |
| How are upgrades delivered, and who controls the window? | Forced upgrades are an operational risk; deferred ones are a security risk. The mechanism decides which you carry. | A stated upgrade cadence per deployment shape, with dedicated change windows where the institution's change control requires them. |
CoreFi as the worked example. CoreFi measures 99.9% platform uptime against operational SLOs across 20+ production deployments serving 200k+ end-customer accounts in 6 geographies: Italy, Spain, France, Argentina, Chile and Bolivia. For the cost-line framework behind the third question, including deployment-model comparisons and the fees vendors externalize, read the core banking TCO article.
Each domain above links to the page where CoreFi's full answer lives, so your architects and procurement team can verify rather than take a summary on trust.
Logical model, deployment shapes, integration surface and security boundary, with diagrams. See /architecture and the API detail in the Developer Center.
Control surfaces, certification status stated exactly, DPA and sub-processor list. See /security-compliance and the Trust Center.
Where CoreFi's archetype fits your problem, and where it does not. See /how-corefi-compares and the executive view on /for-cios.
Bring this page, your current stack and your hardest questions to a working session with the team that operates the platform. We will answer each domain against your environment, in writing where procurement needs it.
All buyer-education guides in one place. Browse the Knowledge Hub.
How to sequence core modernization as bounded, reversible steps. Read the guide.
What operational-resilience rules mean for AI in the core. Read the guide.