How to choose a core banking system comes down to five questions: where it runs, which product engines it includes, how fast it posts transactions, how open its APIs are, and how easily you can leave. Regulators added a sixth in September 2026, when they said core providers’ transparency and contract terms will shape how closely those providers are examined. This guide walks through each question for banks, credit unions and sponsor banks.
What the core actually does
A core banking system is the bank’s system of record. The Federal Reserve’s proposed third-party guide for community banks describes it this way: core systems “manage customer accounts, process daily transactions across deposits and loans, maintain the general ledger, generate regulatory reports, and serve as the integration hub connecting specialized applications.” The same document calls the core provider generally “the most material and complex third party relationship” for a community bank. For a longer primer, see what is core banking.
Because so much depends on the core, the selection is less about features on a demo and more about fit, openness and exit.
Start from your business model
A community bank or credit union serving local customers needs dependable deposit, loan and general ledger processing, plus integrations to digital banking, cards and payments.
A sponsor bank, meaning a bank that holds deposits and moves money for fintech programs, has an extra requirement: many sub-accounts under one program. Fintech programs often use a “for benefit of” (FBO) account, a single custodial account at the bank holding funds for many end users, with a sub-ledger tracking each user’s balance. The FDIC proposed rules in September 2024 that would require banks with custodial deposit accounts with transactional features to keep records identifying each beneficial owner, the balance attributable to each owner and the ownership category, and to reconcile at least daily as of the close of business.
That changes the core question. Can the core itself hold large numbers of sub-accounts, or will you add a sub-ledger beside it? Some vendors sell that layer. Treasury Prime markets a virtual sub-ledger whose sub-accounts sync “in real-time to a head account.” Jack Henry’s developer portal lists a Payments Orchestrator for embedding “multiple payment rails and virtual accounts.” Whichever route you take, ask who owns the beneficial-ownership records and how the bank gets to them if the vendor fails. Sponsor banks weighing partners should also read how to choose a sponsor bank.
Deployment model
There are three broad options:
- On-premise (in-house): the bank licenses the software and runs it on its own hardware or its own cloud tenancy.
- Vendor-hosted (outsourced): the vendor runs the core in its data centers or private cloud and the bank pays per account or per transaction.
- SaaS on public cloud: the vendor runs one maintained codebase on a public cloud provider and ships updates on its schedule.
The model affects contract length, upgrade control and who carries infrastructure risk. Jack Henry’s fiscal 2026 10-K says hosted clients are “typically on a six-year contract” that includes “per account” fees and minimum guaranteed payments, while on-premise clients are “typically on a one-year contract.”
What core vendors publish
The table below uses only what each company states in its filings or official pages. It is not a ranking.
| Vendor | Deployment models it publishes | Client types it publishes | Contract term it publishes | Source type |
|---|---|---|---|---|
| Fiserv | Primarily an outsourced service; can be installed on client-owned systems or ones hosted by third parties | Banks, credit unions, other financial institutions | “Multi-year contracts” (processing and services generally) | 10-K, FY2025 |
| FIS | Managed processing at the client site, in an FIS data center or private cloud; also license and maintenance | Global financial institutions, U.S. regional and community banks, credit unions, commercial lenders | “Multi-year processing contracts” | 10-K, FY2025 |
| Jack Henry | On-premise or private cloud; credit unions also a partner private cloud; a public cloud-native platform in development | Over 900 banks and over 700 credit unions on its cores | Hosted typically six years; on-premise typically one year | 10-K, FY2026 |
| Thought Machine | Bank’s choice of cloud, on-premise, hybrid, or SaaS (2020 release); multi-cloud (current site) | From tier 1 banks to fintechs | Not published | Company site and press release |
| Mambu | SaaS on AWS, Google Cloud or Azure; shared or dedicated environments | From Tier-1 banks to fintechs | Not published | Company site |
| Temenos | On-premises, cloud or SaaS | Banks of all sizes; over 950 core banking clients | SaaS: five-year standard contract | Interim report 2025; annual report 2025 |
Product engines and real-time posting
List the products you run today and the ones you plan: deposits, consumer and commercial loans, cards, and any fintech programs. Then check which run natively on the core and which need a separate system. The Fed’s proposed guide notes that relying on one provider for many services “may offer operational efficiencies” but can create heightened risk if that provider has financial, operational or security problems.
Posting speed matters more as instant payments grow. Ask whether balances update when each transaction arrives or in a nightly batch, and whether any scheduled downtime remains. Vendors now state this directly. Fiserv’s 10-K describes its newest core, CoreAdvance, as offering “real-time processing.” Thought Machine’s Vault Core page claims “zero scheduled downtime.” Ask for evidence in your own test environment, not only in marketing copy.
APIs, documentation and integrations
An API (application programming interface) is how other systems read from and write to the core. Check three things: whether documentation is public before signing, which functions are exposed (account opening, posting, holds, statements), and whether third parties can connect without the vendor acting as gatekeeper.
Some vendors publish a lot. Jack Henry’s jackhenry.dev lists jXchange and SymXchange documentation, with core-specific mapping and error pages for SilverLake, CIF 20/20 and Core Director. Mambu has moved its API documentation to docs.mambu.com. More on patterns in api banking.
If the core cannot integrate with a product you want, the Fed’s proposed guide describes an alternative to replacing it: an integration platform, or middleware, that passes data between the core and other systems through API connections. It also notes that this “extends the value chain” and brings its own risks.
Contract terms: term, deconversion and exit
The FFIEC IT Examination Handbook’s Outsourcing Technology Services booklet calls the contract “the single most important control in the outsourcing process.” Its points map closely to core deals:
- Data ownership: “Ownership of the institution’s data must rest clearly with the institution.”
- Termination: consider rights tied to change in control, convenience, a substantial increase in cost, repeated failure to meet service levels, bankruptcy and insolvency.
- Exit: the contract should provide “timely return of the institution’s data and resources in a machine readable format,” and state any conversion-assistance costs clearly.
- Duration: shorter terms may suit fast-changing technology; align expiration dates of related contracts where practical.
The Fed’s proposed community bank guide adds pricing tied to account counts, asset size or volume; clear billing; the length of any “back billing” window for retroactive charges; initial term and automatic renewal; measurable service level agreements (SLAs); and liability provisions covering security breaches and data protection.
What regulators now expect
On September 11, 2026, the Federal Reserve, FDIC and OCC issued a Joint Statement on Community Banks’ Engagement with Core Service Providers. It says the agencies will weigh three things when deciding how much supervisory attention a core provider gets:
- Transparency: willingness to share due diligence information such as SSAE 18 SOC reports, audit and penetration testing reports and PCI DSS, NIST or ISO assessments; measurable SLAs; timely disclosure of incidents; and billing that can be reconciled.
- Contract features: opaque pricing or billing, long back-billing windows, “unsupported or contractually undefined core deconversion fees,” and “excessive limitations” on unaffiliated vendors integrating with the core.
- Technology: the number and severity of security incidents, handling of end-of-life systems and demonstrated operational resilience.
The statement also says certain core providers may qualify as “institution affiliated parties” under the Federal Deposit Insurance Act, which could expose them to enforcement directly. It does not reduce the bank’s own responsibility.
The same day, the three agencies and the NCUA proposed new third-party risk management guidance to replace the 2023 interagency guidance. It was published in the Federal Register on September 15, 2026, with comments due November 16, 2026. The proposal says core processing relationships are “likely to be assessed by most banking organizations as higher risk.” See our coverage of the third-party risk management guidance proposal.
In practice, use the statement’s three factors as your request-for-proposal checklist. A vendor that will not share SOC reports or define deconversion fees before signing is telling you something.
If you are switching
Moving to a new core is a separate project. In brief, the Fed’s proposed guide lists costs to budget for (licensing, implementation, early termination fees at the old provider, consultants and staff time), suggests asking for historical error and exception reports and references from other institutions, and advises resolving ledger reconciliation issues before go-live and phasing card or loan migrations over time.
