How to evaluate a core banking vendor

Is there a third-party platform underneath the core — an ERP, a generic enterprise runtime, or another vendor's base system?

Watch for: cores built on top of ERP products. Every change to the banking layer may require a change on the layer below, inheriting that vendor's licensing, release cycles, and consulting ecosystem.

Is processing genuinely real-time end to end, or does it still rely on batch windows for ledger, interest, or reporting?

Watch for: "real-time" framing where balances, interest, or reporting are still produced by overnight jobs. Ask for a diagram of the posting path.

Does the platform have hard dependencies on a specific cloud provider, or can it be deployed on-premise and across any cloud — including smaller regional or sovereign providers?

Watch for: hard coupling to a hyperscaler's proprietary services. Cloud lock-in narrows future negotiation and can rule out sovereign or on-prem deployments that Nordic regulators sometimes require.

Are the full API specifications openly published and viewable right now, without an NDA, demo call, or sales conversation?

Watch for: documentation gated behind sales. Count the hops it takes to reach actual specs — every gate is a signal about how integration will feel later.

Is a working sandbox environment provided during evaluation, where the bank's own developers can hit live endpoints and try real flows?

Watch for: evaluations that rely only on demos, slides, or recorded videos. Without hands-on sandbox access, integration risk stays hidden until after signing.

How large is the API surface — how many endpoints, resources, and concepts does a developer need to learn to do basic work?

Watch for: sprawling APIs with hundreds of overlapping endpoints. A smaller, well-shaped footprint is significantly easier to learn, build against, and keep running.

What does the underlying tech stack look like — modern languages and runtimes, or layers of legacy kept alive? Is the system a monolith that scales by adding machines, or a service-oriented architecture with granular per-workload scaling?

Watch for: "scalable" used to mean "we can rent a bigger server." Real horizontal scaling looks like independent services with their own data, deployed and scaled separately.

Does the vendor give the bank's architects and developers direct access to their own systems architects and senior engineers — for design conversations and developer-to-developer Q&A — or does everything go through account managers and support tickets?

Watch for: vendors that hide engineering behind sales. The bank's team needs to talk directly to the people who built the system, both during evaluation and once it's running.

Is the platform delivered as a product, operated per bank, or as a shared multi-tenant SaaS?

Watch for: ambiguity on who runs production, who holds the data, and who absorbs incident response. Get it in writing.

What share of normal year-two changes — products, rates, policies, partners, reports — can the bank's own team ship without the vendor or a certified consultant?

Watch for: "configuration" that in practice requires a certified partner to touch a proprietary language or deploy through a vendor portal, and answers that avoid giving a percentage. Ask for examples and numbers from existing customers.

What is the upgrade model — continuous delivery, scheduled major releases, or bespoke per-customer branches?

Watch for: customer-specific forks that drift from the main product. That pattern makes upgrades expensive and breaks compliance updates over time.

How are compliance updates — KYC, AML, CRS, FATCA, tax reporting — delivered and updated over the life of the contract?

Watch for: compliance as a separate module or partner with its own release schedule, instead of being part of the platform update.

Are API contracts versioned, with explicit deprecation windows for breaking changes?

Watch for: unannounced contract shifts, or an API surface that was generated from the internal data model and therefore churns with it.

Are webhooks and event streams first-class, or do integrations fall back to polling and nightly exports?

Watch for: batch exports used as the primary integration channel. Integrations, risk, and reporting all suffer when state is delayed.

What is the shortest realistic cycle time, in production today, from a bank deciding on a product or rate change to it going live — and where in that path can it block on someone else's release?

Watch for: paths that quietly route through a base-platform update. The bank inherits the cadence of whatever sits below the core; a large platform underneath turns days into months.

What happens operationally when a batch job fails overnight — how is the next business day affected?

Watch for: answers that involve manual reruns, customer-visible delays, or cascading failures across servicing, reporting, and channels. Ask how often this has happened in the last 12 months.

What happens when batch jobs run long — are downstream processes blocked from starting on time?

Watch for: dependent jobs (reporting, interest accrual, statement generation) that wait for an upstream batch to finish, and SLAs that quietly slip when volume grows.

What is included in the license fee, and what triggers an additional statement of work?

Watch for: low headline licenses where regulatory updates, platform modernization, or architecture support are separately billed.

What runtime layers are required in production, and which of them carry their own licensing?

Watch for: stacks that implicitly require an ERP license, a database license, a middleware license, or a managed service beyond the core itself.

What is the expected ratio of annual consulting spend to annual license cost in steady state, after migration?

Watch for: steady-state consulting at one to three times the license. That number is public, common, and usually the largest line item over ten years.

How does cost behave as volume grows — linearly, with peaks for batch windows, or auto-scaled?

Watch for: infrastructure sized to nightly peaks that sit idle during the day. This is a common source of 2–4x operating cost differences.

How does the price scale with the bank's business — per product, per account, per customer, per transaction — and which of those are capped, tiered, or open-ended?

Watch for: per-unit fees that look small at proof-of-concept volumes and dominate the bill at scale. Ask for the all-in cost at the bank's expected three- and five-year volumes, not today's.

Is the supplier willing to take contractual obligations on performance — uptime, latency, batch completion, incident response — with real remedies if they're missed?

Watch for: "best effort" language, SLAs without service credits, or performance commitments that exclude exactly the operations that matter (overnight processing, peak-day throughput, cross-region failover).

On termination — for any reason — what does the vendor commit to in writing: data export format, transition assistance period, run-down support, and a fixed price for all of it?

Watch for: open-ended "reasonable assistance" clauses or transition services priced only on termination. Regulators expect exit terms the bank could realistically execute under stress.

Do the bank and its regulators have a contractual right to audit the vendor — and its sub-processors — on reasonable notice, with cooperation obligations during supervisory reviews?

Watch for: audit rights gated to aggregated SOC reports only, or scopes that exclude sub-processors and operational environments. EBA and Finansinspektionen outsourcing guidance require these rights explicitly.

Are the specific clauses required by DORA for critical ICT services and the EBA outsourcing guidelines written into the master agreement — not bolted on as a separate addendum?

Watch for: "DORA addenda" attached at signing without amending the substantive obligations. Mandatory clauses include exit assistance, audit rights, sub-processor control, security-incident notification, and stress-testing participation.

If the vendor goes insolvent, discontinues the product, or fails to remedy a material breach, what step-in or source-code rights does the bank get — and is the build pipeline, configuration, and operational runbook held in escrow alongside the code?

Watch for: escrow that covers source code only. Code without the build pipeline, infrastructure-as-code, and operational know-how rarely keeps a regulated platform running.

Is every sub-processor (hosting, support, integrations, AI services) disclosed, change-controlled with bank approval, and held to flow-down obligations matching the main contract?

Watch for: blanket consent to "subcontract as needed," or sub-processors in jurisdictions the bank's outsourcing policy would not normally allow. Each one becomes part of the bank's regulatory perimeter.

How are price increases governed — annual caps, indexation to what, and what events outside the schedule can trigger a re-price?

Watch for: indexation that bears no relation to actual usage growth, or re-pricing triggered by vague events like "increased usage" or "new feature adoption."

Who operates the platform today in production, and under what scope?

Watch for: logos without scope. A name is not a reference — ask what they run, with what volume, on what configuration.

What stage is the platform at — early, scaling with design partners, or broadly deployed?

Watch for: vendors that obscure their maturity. Earlier-stage platforms can offer much deeper partnership; broadly deployed ones move slower on your needs. Both are valid — ask directly.

Can the vendor walk a sceptical architect through the actual codebase or a live environment, not only slides?

Watch for: resistance to technical deep dives. A product-led vendor should welcome them.

How is audit lineage captured — per write, per state change, or reconstructed after the fact?

Watch for: audit trails built from reports rather than from an immutable event log. Regulators have started asking for the difference.

Can the bank see who or what made any given data change — user, service, batch job, integration — for every write in the system?

Watch for: change logs that only cover user actions and miss machine-driven writes from services, integrations, or batch jobs. Every write should have an attributable actor on the record itself.

Is there a complete record of who has read which customer or transaction data, when, and from where — including bank staff, support, and integrated systems?

Watch for: read-access logging that's optional, retained only briefly, or that excludes administrative tools and support consoles. Regulators and incident response both need this trail unedited.

For every batch job, can the bank see when it ran, who or what scheduled or triggered it, and — for any failure — when it failed and why, with the underlying error preserved?

Watch for: dashboards that show success or failure status but not the trigger, operator, or full error context. Most batch incidents become hard to investigate because of what was discarded, not what failed.

Does the vendor publish proper change logs with each release — what functionality was added, changed, or removed, and which bug fixes are included — at a level the bank's own change advisory board can review?

Watch for: marketing-flavoured release notes that highlight features but omit removals, internal API changes, or bug-fix detail. The bank's own change record needs to satisfy supervisors, not just inform users.

Can the vendor provide a current SOC 2 (or equivalent) report, and is it shared annually with the bank under NDA — or just a one-page summary?

Watch for: "we're working on it," summaries instead of the actual report, or SOC 2 Type I where Type II is what auditors expect. ISO 27001 plus a recent independent penetration test can be acceptable equivalents.

Can the bank, on demand, see which users have which access today — and pull a complete report of onboarding and offboarding events with timestamps, approvers, and access changes?

Watch for: access reviews that depend on screenshots from admin UIs, or offboarding flows where access removal is not logged. Periodic access recertification is a regulatory expectation; the data has to be exportable.

When the bank needs real-time data out — to a data warehouse, fraud system, analytics, or partner — exactly how is that delivered: change streams, message queues, webhooks pushed by the platform, or polling APIs the consumer pulls?

Watch for: "real-time export" that turns out to be a polling job against an export endpoint, or an event bus that only carries notification headers without payloads. Ask for the actual transport, ordering guarantees, and replay semantics.

Is the full raw data model exposed to integrations and analytics, or only a curated set of summary objects the vendor decided to publish?

Watch for: APIs that expose customer-friendly summaries but hide the underlying ledger, event log, or operational state. Curated objects work until the bank needs a question the vendor did not anticipate.

Are reads and writes separated at the database layer, so that a heavy read workload — analytics, reporting, batch extracts — cannot slow down or destabilise transactional writes?

Watch for: a single shared database where every reporting query competes with live posting. Production incidents often trace back to one analytics workload that was not isolated.

If a separate read copy of the database is available, is it included by default in the standard deployment — or is it a paid add-on that only appears after the first scaling incident?

Watch for: read replicas listed as a premium tier, or charged separately per instance or per query. By the time it is needed, the bank rarely has time to negotiate.

Can the test environment be populated automatically from production data — refreshed on schedule and properly anonymised — without a manual export-and-mask process every time?

Watch for: test environments seeded only with synthetic fixtures, or refreshes that require a vendor ticket each time. Realistic test data is what separates a useful test environment from a demo.

Does the platform have built-in workflows to remove or anonymise a customer's personal data on request — covering live records, the event log, backups, and downstream copies — without bespoke engineering each time?

Watch for: erasure handled as a one-off ticket against the vendor, or scripts that only touch the primary database while leaving immutable logs and replicas untouched. GDPR right-to-erasure has to cover the full data footprint.

Is there a configurable policy engine that automatically removes or anonymises personal data once its lawful retention period expires — per record class, per jurisdiction — without a periodic clean-up project?

Watch for: retention rules documented in policy but enforced by a quarterly script someone has to remember to run. Sustainable GDPR compliance means the platform enforces the policy, not the operations team.