Core Banking Vendor or Systems Integrator: Who Should Own the API Program?
Contents
Introduction
Banks can buy modern platforms with extensive APIs and still find themselves responsible for making the full technology estate work. The key decision is not which systems can connect, but who will own the connections in production.
A modern financial service rarely runs on one platform. The core banking system maintains accounts and balances. Separate providers may handle domestic and international payments, card issuing, identity verification, transaction monitoring and regulatory reporting. Mobile and web applications add another layer.
Most of these products provide APIs. Yet the availability of an API says little about who will design the full transaction flow, resolve inconsistencies between systems or take responsibility when a customer-facing process fails.
That responsibility must sit somewhere. A bank can assign it to the core banking vendor, appoint an independent systems integrator or build the capability internally. Each model can work, but the choice has significant implications for cost, delivery risk and long-term operating capacity.
Do APIs Define Your Core Banking Operating Model?
An API allows systems to exchange information. It does not determine how the institution should process that information. Consider a payment instruction. The core platform may create the transaction and reserve the customer’s funds, while an external processor executes the payment. The institution must still define what happens if the processor times out, returns an unexpected status or completes the payment after the core has marked it as failed.
The same challenge appears in card processing. Authorisations, reversals, clearing records, settlements and chargebacks arrive at different stages. Those events must be reflected correctly in the customer balance and the institution’s accounting records.
KYC and AML integrations also require more than technical connectivity. A verification provider may return a result, but the bank must decide how that result affects onboarding, which cases require manual review and what information should be retained for audit purposes.
These decisions sit between products. They require banking knowledge, operating-model design and a clear view of which system is authoritative at each stage.
Mambu vs. Temenos vs. Fiserv vs. Jack Henry: How Their Delivery Models Differ
Mambu, Temenos, Fiserv and Jack Henry all support integration-led banking architectures, but they approach delivery from different positions.
Mambu is designed around composable banking. Institutions can use its cloud-native core while selecting independent providers for payments, cards, compliance and customer experience. This offers flexibility, particularly for new digital banks and fintech companies.
The model also requires careful allocation of responsibility. Mambu can support implementation, but a broader programme may involve a separate systems integrator and several specialist vendors. The institution should establish who owns the architecture around the core and who will coordinate the external providers after launch.
Temenos offers a wider banking platform, covering core banking, payments and digital capabilities. It is well suited to larger transformation programmes where the institution wants substantial functionality from one product family.
Temenos also works through an extensive implementation-partner network. That gives banks access to significant delivery capacity, although responsibility may be shared between the software vendor, the implementation partner and third-party providers. Strong programme governance is therefore essential.
Fiserv combines core banking, payments, card processing and digital banking services. It can take a substantial role in implementation and is particularly relevant where a bank plans to use several Fiserv products.
Concentrating more of the stack with one supplier can reduce the number of commercial and technical interfaces. Banks should still examine how easily the proposed architecture can accommodate external products and who will investigate incidents involving systems outside the Fiserv estate.
Jack Henry has a strong position among US community and regional banks and credit unions. Its integration ecosystem allows fintech providers to connect directly with Jack Henry core platforms using established technical frameworks.
This can reduce the burden on institutions already operating within the Jack Henry environment. Its relevance is more limited for international fintech programmes or institutions seeking a delivery partner across several jurisdictions and unrelated technology providers.
All four vendors can support integration. None should be assumed to own the complete operating environment unless that responsibility is expressly included in the engagement.
When Should Your Core Banking Vendor Lead Integration?
The core banking vendor is often the logical integration lead when the institution is adopting a broad suite from the same supplier. A bank selecting its core, payments platform and digital channels from one company may benefit from keeping delivery responsibility close to that vendor. Fewer boundaries can simplify architecture, contracting and incident management.
The core vendor also understands the ledger and transaction model better than any external party. That knowledge is particularly valuable when integrations affect balances, fees, posting rules or end-of-day processing. The model becomes less straightforward when the technology estate is highly diverse.
A regulated fintech may use one company for the core, another for banking infrastructure, separate processors for payments and cards, and several compliance providers. The core vendor may support the necessary interfaces without accepting responsibility for how the complete service performs. Ownership of the ledger should not be confused with ownership of every process connected to it.
When Should You Use an Independent Systems Integrator Instead?
An independent systems integrator is better placed to lead when the programme crosses several vendor boundaries or when the institution intends to retain its existing core.
The integrator can design the target architecture without making core replacement a condition of the engagement. It can also coordinate providers that have different commercial priorities, release schedules and technical standards. This role requires more than general software engineering.
The integration partner must understand how financial transactions move from customer instruction to final accounting. It needs to design posting logic, payment states, card settlement processes, reconciliation and exception handling. It must also know which record should prevail when two systems provide conflicting information.
Velmie operates in this part of the market. The company provides a digital banking platform, but it also undertakes integration programmes around third-party core systems. Its delivery scope can include payment rails, card processors, KYC and AML services, reporting systems, operational back-office tools and customer channels.
This model is relevant where the institution wants one delivery team to coordinate the wider technology environment without requiring every component to come from the same vendor.
Velmie can provide its own banking platform where a new core or operating layer is required. It can also work with the institution’s existing core and selected financial providers.
The distinction is important. The value is not simply access to another API catalogue. It is the allocation of responsibility across systems supplied by different companies.
Who Owns Integration After Go-Live? Why Implementation Isn't Enough
Many integration engagements end at go-live. The implementation team completes development, supports testing and hands the interfaces to the institution. Production incidents are then divided among several support desks.
The payment processor confirms that it returned the correct response. The core vendor confirms that the transaction was posted according to its configuration. The digital-channel provider confirms that the application displayed the status it received.
All three statements may be correct, while the customer still sees the wrong balance.
A workable delivery model must continue into production. Someone needs to examine the full transaction rather than stop at the boundary of a particular system.
That responsibility includes maintaining interface documentation, monitoring changes introduced by external providers and coordinating releases that affect several parts of the platform. It also requires a clear process for incident management and escalation.
Velmie’s model extends beyond implementation into maintenance, managed change and ongoing platform development. This continuing role is central to its position as a systems integration partner rather than a supplier of isolated software components.
Reconciliation and Reporting Cannot be Deferred
Integration programmes often prioritise the real-time customer journey. Reconciliation and reporting are left until the principal transaction flow is working. That approach creates avoidable problems.
Payment and card integrations need to produce records that can be compared with bank statements, processor files and settlement reports. The programme must define how discrepancies will be identified, assigned and resolved.
Reporting creates similar dependencies. The core and external providers need consistent customer identifiers, transaction references and status definitions. Corrections and reversals must remain visible rather than being overwritten or reconstructed later.
A partner that delivers the real-time API but excludes reconciliation and operational reporting has implemented only part of the service.
Velmie includes data flows, reconciliation interfaces and reporting requirements within the wider integration design. This allows the institution to consider the complete operating process rather than treating reporting as a separate project after launch.
Accountability Must be Explicit
The lead integration partner should control the target architecture and the contracts between systems. Individual vendors will continue to own their products, but one party should understand the full service and coordinate the dependencies between them.
The scope should address:
system and data ownership;
interface versioning;
transaction states and error handling;
end-to-end security and performance;
reconciliation and reporting;
integrated testing;
incident management after launch.
Testing should cover more than successful transactions. Timeouts, duplicated requests, delayed responses, rejected payments and inconsistent provider statuses are part of normal financial operations. The institution needs to know how the platform will behave in each case.
Commercial terms should reflect this wider responsibility. An accountable integration engagement will cost more than a narrow API-development contract, but the comparison should include the internal architecture, engineering and support capability the institution would otherwise have to build.
Core Vendor or Independent Integrator: How to Choose the Right Model
A core banking vendor is usually the right integration lead when the bank is adopting a broad suite from that vendor and wants to minimise the number of independent components.
An independent systems integrator is more appropriate when the institution plans to retain its core, combine products from several providers or avoid building a large internal integration function.
Mambu, Temenos, Fiserv and Jack Henry can each play an important role, depending on the institution’s market, platform strategy and existing technology estate. The procurement process should still determine whether they will take responsibility beyond their own products.
Velmie is positioned for programmes where the principal requirement is broader delivery ownership. It can supply the banking platform where needed, but its more distinctive role is coordinating the systems around the core and remaining involved after they enter production.
The most useful procurement question is therefore not whether a vendor provides the necessary APIs.
It is who will be accountable when the core, payment processors, card systems, compliance providers and reporting tools must operate as one regulated service.
