Build, Buy or Partner

Strategic choices across capability, speed, cost and control

Choose the capability before its supplier

Build means developing and operating a capability internally. Buy means obtaining a product or service from another firm. Partner means coordinating complementary capabilities and responsibilities across firms. A bank often combines all three: buying a platform, building its integration and partnering for distribution.

Describe the customer task, important financial effects and required operating capabilities first. Distinguish the software needed from the legal activity and service being delivered. Buying a technology platform does not automatically transfer a banking licence, and partnering with an authorised entity does not grant unlimited permissions to every participant.

Compare realistic alternatives

Evaluate differentiation, delivery time, staffing, control, integration, security and dependency. An internal build still depends on libraries, infrastructure and specialist people. A purchased service can provide effective configurable controls if its capabilities, access and evidence are adequate. Neither choice is inherently safer or always faster.

Use realistic demonstrations and representative failure scenarios. For fraud decisioning, test latency and outcomes in the actual authorisation path, including outage behaviour and controlled rule changes. For statements, test accuracy, accessibility, retention and retrieval. A standard demo cannot establish every requirement for a bank's specific estate.

Price operation, change and exit

Total cost includes implementation, migration, integration, licences, usage fees, support, assurance and ongoing changes. Also consider contract escalation, volume assumptions, retained staff and exit costs. Restricted funds and capital requirements are not ordinary software expenses, but they can affect the overall financial feasibility of a proposition.

Compare scenarios rather than a single optimistic forecast. Higher volume can improve a fixed-cost build's unit cost while increasing a purchased service's usage charges; contractual tiers, staffing and capacity limits can change that relationship. Explain assumptions and avoid treating contribution margin as total enterprise profit.

Control and continuity

Map critical dependencies, subcontractors, records, decision rights and incident responsibilities. Obtain access and information needed to meet applicable obligations. A bank cannot assume that outsourcing removes its own regulatory responsibilities, although exact duties and allocation among firms follow the applicable law and arrangement.

The Basel Committee's 2025 third-party-risk principles provide a bank-risk framework, with local implementation relevant. Translate the framework into the relationship's actual controls and evidence; do not invent universal concentration thresholds or identical review schedules.

Exit needs usable records, migration behaviour and a plan for continuing obligations. Not every investment is fully reversible. Assess sunk costs and difficult dependencies honestly, and consider continuity or run-off where immediate substitution is unrealistic.

Fictional example: statement service

A bank compares an internal statement engine with a hosted service. The hosted option reaches the required functionality sooner but charges by volume. A pilot tests corrected statements, historical retrieval, access failure and export into an alternative viewer.

The bank chooses the hosted service with identified retained responsibilities and migration costs. It monitors costs and service quality as volumes change. The choice remains defensible because evidence supports its assumptions, not because buying is universally preferable.

Takeaway

A sourcing decision should explain what will operate, who controls it, what it costs and how obligations continue during failure or change. Review those assumptions when the business, provider or risk changes.

Continue to Bank Fintech Partnerships.