AI & Banking
Build or buy bank AI: what should remain in-house
Why banks tend to build customer analytics and credit scoring while sourcing more fraud, cybersecurity and reporting capabilities.
•
acceleraid Redaktion
6 min read

Build or buy bank AI is often framed as a technology choice. For senior management, it is better understood as a decision about where the bank must own knowledge, accountability and change—and where an external provider can add scale without creating an unmanaged dependency.
The market is already beyond experimentation. The ECB reports that 85% of large EU banks use AI, while euro-area significant institutions invested more than €4 billion in digital technologies including AI in 2025, around 1.3% of tangible assets (ECB, 23 March 2026). Those figures establish materiality, not a universal sourcing answer.
The observed pattern—and its limit
Banks typically build in-house when AI depends closely on proprietary knowledge, notably credit scoring and customer analytics; they rely more on external providers for fraud detection, cybersecurity and regulatory reporting (ECB). The source provides no percentage split between build and buy, so the pattern should guide inquiry rather than become a benchmark.
The same ECB speech reports adoption above 50% for fraud and cybercrime detection, around 50% for marketing, 40% for chatbots and 30% for credit scoring (ECB). These are use-case adoption rates, not sourcing shares. Philip R. Lane also states that the views in the speech are his own and do not represent the Governing Council’s collective view (ECB).
Why customer analytics tends to stay inside
Customer analytics draws its advantage from context that vendors rarely possess: product holdings, channel behaviour, service events, consent status, relationship history and the bank’s own commercial vocabulary. The model is only one component; value comes from the decision loop connecting data, treatment, frontline action and measured outcome.
Acceleraid recommendation: keep the customer decision layer, feature definitions and outcome measurement under bank control even when external components are used. A governed Customer Brain can make this boundary explicit: providers may supply infrastructure or models, while the bank owns customer meaning, permitted use and intervention logic.
This is also a change-economics issue. Customer strategies, products and consent rules evolve continually. If every feature or decision-policy change requires a vendor release, the bank can lose the learning speed that justified AI investment in the first place.
Why credit scoring tends to be built
Credit scoring embeds risk appetite, portfolio history, underwriting policy and local data quality. It also influences decisions that must be explainable, monitored and challenged. The EBA says AI used to evaluate a natural person’s creditworthiness or establish a credit score is high-risk under the AI Act (EBA mapping).
In-house does not mean “owned by data science.” Acceleraid recommendation: assign joint ownership across business, risk and technology; retain reproducible training data, versioned policies, performance and fairness monitoring, override analysis and an auditable path from input to decision. External tools can support development, but accountability should not disappear behind a platform boundary.
The legal role also changes with sourcing. The EBA mapping says a financial institution developing an AI system in-house may be both provider and deployer, whereas a bank using a third-party system is the deployer (EBA). “Build” can therefore increase obligations as well as control.
Why fraud, cyber and reporting lean external
Fraud and cybersecurity benefit from signals across institutions, specialised threat intelligence and rapidly updated detection content. Providers can amortise scarce expertise and infrastructure across many clients. Regulatory reporting platforms similarly encode changing formats, validation rules and submission workflows that are expensive to maintain independently.
Buying does not transfer the outcome. ECB Banking Supervision notes that generative AI is often sourced from a small number of major providers and depends heavily on cloud infrastructure and general-purpose models that are not fully transparent to users (ECB Banking Supervision, 24 February 2026). It highlights concentration, lock-in, confidentiality, security, resilience and exit-strategy concerns (ECB Banking Supervision).
Acceleraid recommendation: buy capabilities, not opacity. Contracts and operating models should secure access to performance evidence, material-change notification, incident cooperation, sub-outsourcing visibility, tested continuity options and usable data export. The bank remains the deployer for third-party AI under the EBA mapping and must govern use accordingly (EBA).
Use an ownership matrix, not a binary vote
A practical decision separates six layers: data, model, orchestration, decision policy, user experience and monitoring. A bank may buy a foundation model, build retrieval and policy logic, operate on approved cloud infrastructure, and retain monitoring and customer treatment in-house. “Hybrid” is meaningful only when ownership at each layer is explicit.

Acceleraid recommendation: score each layer against five questions. Is proprietary knowledge the main source of advantage? How severe is harm from error or drift? How quickly must the capability change? Can the bank independently evidence performance? Is exit operationally credible within the required recovery horizon?
Use the result to set architecture and governance together. High proprietary value and high decision impact favour internal ownership of data semantics, policy and monitoring. High scale economies with standardised outputs may favour providers, provided evidence rights and exits are real.
Acceleraid recommendation: add a “minimum viable independence” test before approval. The bank should be able to explain the output, detect material deterioration, continue critical operations during a provider disruption and migrate the necessary data without depending on the same provider that has failed. If it cannot, price the remediation into the buy case rather than treating dependency as an afterthought.
The bank’s operational-risk design should connect this matrix with third-party, model, data and change controls rather than create an AI-only lane. Our review of the EBA operational-risk framework explains why integrated evidence and accountability are essential when automation crosses functions.
Regulation is complementary, not interchangeable
The EBA’s mapping found no significant contradictions between the AI Act and EU banking and payments rules and described the AI Act as complementary to existing sector requirements (EBA). That does not mean one control framework automatically satisfies the other.
The document explicitly says the mapping is not guidance, supervisory expectations, an official or legal position, or advice, and notes that future Commission guidance and harmonised standards may bring clarification (EBA). Banks should use it to map responsibilities, then obtain legal and supervisory interpretation appropriate to their implementation.
Make the decision reviewable
A production-ready build-or-buy decision should leave a concise record: intended outcome, system boundary, provider/deployer role, data rights, performance baseline, human oversight, change authority, incident responsibilities, concentration assessment and exit test. The management body should be able to see which risks are accepted and which remain conditional on controls.
Acceleraid recommendation: revisit the decision when data scope, model purpose, provider stack, regulation or business criticality changes—not only at contract renewal. The right sourcing choice is a governed hypothesis. Its continuing validity must be demonstrated through outcomes and evidence.
Five takeaways
Treat build or buy bank AI as an ownership and accountability decision, not a procurement shortcut.
Keep proprietary customer meaning, credit policy and decision monitoring close to the bank.
Use providers where cross-market scale and specialised expertise matter, but retain evidence and exit rights.
Define provider and deployer roles before approval; in-house development can make the bank both.
Record the decision by layer and review it whenever purpose, data, dependency or impact changes.
Illustration: AI-generated. AI-assisted content: We use AI technologies and automated agents in the creation of our articles, including from Microsoft, Google, OpenAI, Anthropic and other providers. Topics, editorial direction and final approval remain with our team.
Further Insights
We use cookies 🍪
Strictly necessary cookies, such as for Pipedrive forms, remain active. With your consent, we also use Google Analytics for analysis and Leadfeeder for visitor identification. You can find further information in our privacy policy.
Decline
Accept all