Banks should separate core balance-sheet and trust functions from services that can be delivered more efficiently by specialists. The right test is not whether a startup can copy a bank feature, but whether the bank still needs direct control to manage risk, customer confidence, and regulatory obligations. Partnerships work best when they reduce cost without weakening accountability, data control, or service continuity.
How banks should separate core capabilities from partner-deliverable services
Banks should keep the capabilities that define prudential control, customer trust, and regulatory accountability, then compare everything else on risk-adjusted operating value. Core balance-sheet functions, decisioning that affects the bank’s own obligations, and services that require tight data custody usually stay in house. Commodity or specialist capabilities can move to partners when governance, continuity, and oversight remain intact.
The practical test is whether outsourcing changes the bank’s ability to explain, control, and defend the service to regulators and customers. If the answer is yes, the bank needs stronger internal ownership even if the service can be delivered more cheaply elsewhere.
For services that sit closer to the edge of the institution, banks should evaluate whether the external provider is acting as a processor, a utility, or a de facto co-owner of the customer experience. The more the partner touches sensitive data, identity flows, payment movement, customer communications, or operational continuity, the less this is a simple procurement decision and the more it becomes a governance and resilience decision.
What makes a function worth keeping in house
Functions are strongest candidates to retain when they are directly tied to risk acceptance, regulatory commitments, franchise trust, or differentiated control over customer outcomes. That usually includes balance-sheet management, final approval of material credit or fraud decisions, core records, key control points, and any process where the bank must be able to recover, prove, and override quickly.
In-house control is also justified when the service needs deep integration with controls the bank cannot safely delegate, such as data retention rules, auditability, escalation paths, or recovery orchestration. Even if a partner can operate the workflow, the bank still needs direct authority where failure would create conduct risk, operational fragility, or an accountability gap.
A useful rule is to ask whether the service is merely executed for the bank or whether it materially shapes the bank’s risk posture. If the second is true, the bank should resist treating it as a vendor convenience problem.
When FinTech partnerships make better sense
Partnerships are strongest for modular services where the bank benefits from specialist speed, better user experience, or lower unit cost without surrendering the right to supervise outcomes. That often includes narrow product features, customer-facing enhancements, analytics-heavy adjunct services, and operational utilities that can be contractually bounded and independently monitored.
The best partnerships are designed so the bank keeps policy ownership, data governance, and exit rights, while the partner delivers a bounded capability. This works only when the bank can see what the partner is doing, test continuity assumptions, and replace the provider without rebuilding the entire service stack.
In practice, the more interchangeable the function is, the more attractive partnership becomes. The more irreversible the dependency, the more cautious the bank should be.
How to make the operating model decision without drifting into outsourcing by default
Decision-makers should use a structured cut between strategic control and specialist execution. A bank should usually keep control where loss of service would affect customer protection, regulatory reporting, liquidity, payments integrity, or incident recovery, and should partner where the main benefit is faster delivery of a well-bounded capability that does not weaken those controls.
The most common failure is to outsource because a service looks non-core today, then discover later that it became a control dependency. That is why banks need explicit criteria for data access, operational handover, termination rights, and service continuity before signature, not after the partnership becomes embedded.
For a useful external control lens on the surrounding security and governance requirements, banks can align the model with NIST Cybersecurity Framework 2.0 and the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where third parties affect access control, auditability, and continuity.
Risk and Threat Considerations
Partnering can create concentration risk, hidden control loss, and recovery dependency if too many important services sit with the same vendor or the same integration path. It also expands the attack surface through third-party access, data exchange, and operational coupling, so a good commercial rationale can still produce a weak security outcome if oversight is light.
Failure mechanism: The bank loses practical control over data, change management, access paths, or failover behaviour, then cannot contain an incident or exit the service quickly when the provider degrades or is compromised.
Impact: Customer harm, regulatory findings, service disruption, and a loss of confidence that the bank can still govern the activity it remains accountable for.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Banks must classify core vs partner-deliverable services by business and risk context. |
| GV.RM-01 — Risk Management Strategy | The keep-vs-partner decision is fundamentally a risk appetite and tolerance choice. | |
| GV.SC-01 — Cybersecurity Supply Chain Risk Management | FinTech partnerships introduce third-party dependency and concentration risk. | |
| Recommendation — Define which services remain strategic and which can be outsourced under governance. Set outsourcing thresholds that reflect risk, resilience, and accountability. Assess partner dependencies and enforce exit, monitoring, and resilience requirements. | ||
| NIST SP 800-53 Rev 5 | SA-9 — External System Services | FinTech partnerships are external services that require explicit security and oversight terms. |
| AC-20 — Use of External Systems | Partner-delivered services often rely on external access paths and controlled usage. | |
| CP-2 — Contingency Plan | Continuity and exit planning are central when banking services depend on a partner. | |
| Recommendation — Require security requirements, monitoring, and accountability terms for external services. Restrict and govern use of external systems that touch bank data or processes. Test recovery and fallback plans for partner-dependent services. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Bank-to-FinTech decisions are supplier-risk decisions requiring structured oversight. |
| A.5.21 — Managing information security in the ICT supply chain | The question hinges on supply-chain dependency, continuity, and control assurance. | |
| A.5.30 — ICT readiness for business continuity | Banks must retain recoverability when a partner-hosted service becomes unavailable. | |
| Recommendation — Apply supplier controls before transferring any material service component. Assess ICT supply-chain dependencies and enforce security requirements through the chain. Validate recovery and continuity arrangements before moving critical services out of house. | ||
Practitioner Guidance
What to prioritise: Rank services by how much they affect customer trust, regulatory exposure, and recovery options, not by how modern or “FinTech-friendly” they sound. If a partner can improve speed but the bank cannot clearly retain oversight, the service is probably too close to the core to outsource casually.
What to verify: Confirm the bank can still audit the service, revoke access, recover data, and switch providers without operational collapse. If those four tests are weak, the relationship is not yet a true partnership model, it is a dependency.
Practitioner takeaway: The right boundary is not internal versus external, it is controlled versus uncontrolled. Banks should keep the functions where accountability must remain unambiguous, and partner only where the bank can still prove it owns the risk.
Related resources from NHI Mgmt Group
- How should ecommerce teams decide what to keep in-house versus outsource as they scale operations?
- How should banks and FinTech teams decide which embedded finance model to use first when they want to add financial services inside another customer journey?
- When does an NHI become too risky to keep as-is?
- How should teams decide when to keep a static secret versus migrate to federation?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
