AI for banks, asset managers, fintech and insurers
AI in the financial sector is simultaneously transforming fraud detection, AML/KYC automation, credit scoring, document AI on contracts and KIID/PRIIPS generation. We build models and integrations that operate within the framework of the AI Act, DNB/AFM supervision, EBA Guidelines and DORA, with audit trails, model risk management and verifiable explainability as starting points rather than afterthought documents.
Schedule a conversation Explore applicationsAI in finance: opportunities and frameworks in parallel
The financial sector processes vast volumes of structured transaction data, unstructured contracts, KYC files and market information. That makes it one of the most suitable sectors for AI, and at the same time one of the most heavily regulated. For banks, asset managers, fintech players and insurers, every AI system requires a design that addresses traceability, explainability and governance alongside accuracy from day one.
Wij ontwikkelen AI-oplossingen voor financiële organisaties die zowel CTO/CIO als de tweede en derde lijn (risk, compliance, internal audit) moeten kunnen verdedigen. Dat betekent: model-risk-management volgens SR 11-7-principes, EBA-guidelines voor model-validatie, een werkende koppeling met het bestaande DNB/AFM-rapportagelandschap en operational resilience zoals DORA dat vraagt. Geen labs-experimenten zonder eindstation — wel productie-AI met een houdbare governance-laag eronder.
On this page we outline the key applications: from transaction anomaly detection and AML/KYC to credit scoring (where the AI Act classifies it as high-risk), document AI on credit agreements and ISDA paperwork, automated KIID/PRIIPS generation, customer service AI within MiFID II boundaries, sentiment analytics on market data, and the firm limits around robo-advisory.
Application areas for AI in finance
Eight concrete domains where AI delivers direct value within the prudential frameworks of banks, insurers, asset managers and fintech players. Each domain requires its own risk classification and governance approach.
Fraud detection and transaction anomalies
Real-time scoring of payments, card transactions and account openings against anomaly patterns. A combination of rule engines, gradient-boosted trees and sequential neural models, embedded in a feedback loop with fraud analysts so that false positives genuinely decline rather than remaining structurally high.
AML/KYC automation
Document extraction from identity documents, UBO research, sanctions list screening and ongoing transaction monitoring within a single pipeline. AI speeds up human assessment, but every high-risk decision remains a documented human check, in line with the Wwft and the EBA Guidelines on ML/TF risk management.
Credit scoring and credit approval
Under the AI Act, creditworthiness scoring is explicitly classified as high-risk. That requires a conformity assessment, a risk management system, training data governance and logging that you can present in full detail. We design scoring models that deliver a complete audit package alongside performance.
Document AI on credit agreements
Extraction and classification of clauses from credit agreements, ISDA Master Agreements, CSAs and intercompany loans. Automatic detection of clauses that deviate from a bank standard, and integration with the credit administration system for downstream reporting and covenant monitoring.
KIID/PRIIPS document generation
Generation and periodic updating of Key Information Documents and PRIIPS fact sheets based on fund and product data. Built-in validations for mandatory sections, language versions and change detection against the previous version, so that compliance can review rather than draft manually.
Customer service AI under MiFID II
Chat and voice assistants for retail and private banking clients that stay strictly within non-advice boundaries. The distinction between providing information and giving investment advice is firm under MiFID II, and we design the prompts, guardrails and escalation paths explicitly around that boundary.
Sentiment analytics on market data
NLP on news feeds, earnings calls, broker research and social data to aggregate sentiment signals at instrument level. Intended as input for portfolio managers and quantitative teams, not as an automated order trigger without human review and trading limits.
Robo-advisory within clear boundaries
Fully automated investment advice falls under MiFID II with the same suitability assessment as human advice. We build advice workflows with a transparent factor engine, suitability checks, escalation to a human adviser and an audit log that the regulator can reconstruct.
Insurance AI: claims and pricing
Claims triage, fraud detection on claims, automated first notice of loss and support for risk pricing. EIOPA expects insurers to ensure AI governance, fairness and explainability explicitly, particularly for products that directly affect premiums or cover.
Compliance first: AI Act, DNB/AFM, EBA, EIOPA and DORA
An AI system in finance is not "ready" because it scores accurately on a test set. It is ready when it demonstrably meets the combined requirements of the AI Act, sector supervision and operational resilience. We build those frameworks into the architecture rather than mapping them afterwards.
AI Act high-risk: what it concretely requires
The AI Act explicitly classifies credit scoring, life and health insurance pricing and certain HR applications as high-risk. That means a working risk management system across the full lifecycle, data governance over training and test data, technical documentation, logging, human oversight, robustness and cybersecurity, plus a conformity assessment before market introduction.
DNB and AFM supervision of AI
DNB has published General Principles for the Use of AI in the Financial Sector: soundness, accountability, fairness, ethics, skills and transparency. The AFM, from a conduct supervision perspective, looks at duty of care and market integrity. Both require demonstrable governance, explainable models and a working human override.
EBA Guidelines en model-risk-management (SR 11-7)
EBA-richtlijnen voor model-risk-management, ICT en outsourcing zijn de feitelijke meetlat voor banken. SR 11-7 (Federal Reserve) wordt door grote internationale spelers als de facto standaard gehanteerd: development, implementation, use en validation moeten onafhankelijk gescheiden zijn met onafhankelijke modelvalidatie.
DORA: operational resilience for AI systems
DORA sets requirements for ICT risk management, incident reporting, resilience testing, third-party risk and information sharing. AI systems fall fully within its scope, which affects cloud choices, model hosting, vendor lock-in with LLM providers and how we design fallback paths into the architecture.
EIOPA and insurers
For insurers, the EIOPA AI governance principles framework applies alongside Solvency II. Fairness and explainability in pricing and claims handling are under particular scrutiny, as indirect discrimination through proxy variables is a real and demonstrable risk.
GDPR and purpose limitation
Training data drawn from customer records falls directly under the GDPR: lawful basis, purpose limitation, retention periods and the right to explanation in automated decision-making (Article 22). We keep training, test and production data strictly separate and document the purpose limitation for each dataset.
How we build AI systems for finance
Our approach always starts with one question: which framework does this system fall under, and which risk classification fits it? Only then do we move on to model selection, dataset and architecture. This prevents a promising proof of concept from later falling over on compliance.
Discovery with risk and compliance involved
For an AI discovery project in finance, we involve second-line risk and compliance from day one. The use case, data basis and initial risk classification are settled before we move on to the build phase. You can also read about our approach at /ai-discovery-workshop.
Model validation and challenger models
For high-risk models, we work with an independent validation track and challenger models. Performance measurement, stability, fairness testing across relevant segments and stress testing under extreme scenarios are documented in a model validation report that can be handed over to second and third line.
Audit trails and logging by design
Every model decision that affects a customer or a supervisory report is recorded: input features (hashed where necessary), model version, score, decision and the human override. Audit trails are a first-class architectural component, not a log file that can be rotated away by accident.
MLOps with model risk controls
Pipelines with automated data quality checks, drift detection, retraining triggers and clear promotion gates from staging to production. A model only goes live after a documented sign-off from the model owner, validation and compliance. Similar to our approach to predictive analytics dashboards.
Privacy architecture and data segregation
Data classification, pseudonymisation, key management and strict separation between training, testing and production. For LLM applications, this means no customer data goes to an external provider without a DPA, an update to the record of processing activities and a DPIA in place.
Integration with core banking and policy administration
Our AI rarely lands on a greenfield; usually it has to integrate with a core banking system, policy administration, ERP or GRC tooling. We build event-driven integrations there, with idempotency and dead-letter queues. See building a core banking platform.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Tools and stack we use
A combination of classical ML, gradient boosting, sequential models and, where appropriate, large language models. Not every use case needs an LLM: for scoring, a transparent boosted tree often performs better, whereas for document extraction an LLM with retrieval is the better fit.
Models and frameworks
Python with scikit-learn, XGBoost and LightGBM for scoring, PyTorch for sequential models, Hugging Face and OpenAI/Azure OpenAI for document and language applications. SHAP and counterfactual explanations for explainability, and Fairlearn plus internal metrics per protected segment for fairness checks.
Data infrastructure
Snowflake, Databricks or BigQuery as the data platform, dbt for transformations, Apache Kafka for event streams and Airflow for batch pipelines. Strict separation between development, acceptance and production environments, with separate keys and roles.
MLOps and monitoring
MLflow or Vertex AI for model registry and lineage, Evidently or WhyLabs for data and model drift, Prometheus and Grafana for service metrics. Alerts on drift, latency and exceptions are routed straight to the model owner team and the on-call SRE.
Cloud, security and DORA fit
Azure, AWS and Google Cloud are all workable, provided you configure cloud region, encryption at rest and identity management correctly. For DORA third-party risk, we document the chain of sub-processors, exit strategy and concentration risk explicitly in the solution architecture.
Security, governance and model risk management
In finance, security is not a separate module at the end; it is a precondition of the design. This applies doubly when AI models feed into customer decisions or supervisory reporting.
Three lines model in the architecture
The business line builds and uses the model, risk management and compliance validate it independently, and internal audit reviews the entire chain. We make that separation concrete through segregated environments, role-based access and a review flow in which no model goes to production without the four-eyes principle.
Explainability for the customer and the supervisor
For automated decision-making, GDPR Article 22 gives the customer the right to an explanation. Supervisors want to be able to reconstruct why a model gave a particular score in a specific case. We address this with SHAP explanation endpoints, a readable reason string for customer communication and a complete feature snapshot in the audit log.
Operational resilience and fallbacks
DORA requires demonstrable resilience: what happens if the LLM provider goes down, what if a feature store fails, how quickly we can revert to a backup model. We design circuit breakers, fallbacks to a previous model version and, where possible, a manual route so the business does not grind to a halt.
Vendor lock-in and LLM governance
An AI stack that depends entirely on a single LLM provider is a DORA concentration risk. We abstract model providers behind an internal facade so you can switch models, run them locally where necessary, and ensure your choice of vendor does not determine your compliance position.
Penetration testing and model attacks
Alongside standard penetration tests, we look at model-specific attack vectors: prompt injection, data poisoning, model extraction and evasion attacks on fraud detection. For production LLMs, we build an input/output sanitisation layer with explicit detection and logging.
Alignment with DORA compliance software
The AI system must deliver the right signals for your wider DORA reporting: incident classification, third-party overview, resilience test results. Read our approach to DORA compliance software and AI Act compliance software.
Frequently asked questions about AI in banking and finance
When is an AI application in finance "high-risk" under the AI Act?
The AI Act explicitly classifies creditworthiness assessment and certain insurance pricing applications as high-risk. This brings obligations around risk management, data governance, technical documentation, logging, human oversight, robustness and a conformity assessment before market introduction. A fraud detection model is not automatically high-risk, but it often still falls under DNB or AFM expectations on explainability and model validation.
Can an LLM give investment advice directly?
Under MiFID II, fully automated investment advice is permitted, but exactly the same suitability assessment applies as for human advice: knowledge, experience, risk tolerance and objectives must be recorded, and the advice must fit them. A chatbot without those built-in checks therefore may not give advice; we set strict guardrails on the distinction between information and advice.
How do you approach DNB expectations on AI governance?
We work from the DNB General Principles for the Use of AI: soundness, accountability, fairness, ethics, skills and transparency. In practice this means a documented model owner, a working model risk framework, fairness tests across relevant segments and an explainability layer that works not only technically but also towards the customer. Our deliverables are structured so they are directly usable in a conversation with DNB or AFM.
How does this fit within DORA?
DORA affects AI systems through ICT risk management, incident reporting, resilience testing and third-party risk. We document the chain of model providers, design fallback models and make sub-processors visible in the third-party register. We carry out resilience testing (TLPT where applicable) not only at the application layer but also on the model: what happens if the LLM provider is unavailable, and what if a feature store becomes corrupt.
Can you integrate AI models with our existing core banking or policy system?
Yes, in almost every project the model lands in an existing landscape of core banking, policy administration, ERP and data platform. We work with event-driven integrations via Kafka or a service bus, idempotent endpoints and clearly defined contracts, so the model stays decoupled from the system of record.
What explainability do your models offer?
For scoring models, we deliver SHAP or comparable feature attributions per decision, plus a translated reason code for customer communication. For LLM applications, we deliver the prompt, retrieved context and a trace so a compliance officer can reconstruct why the model produced a given outcome. For high-risk applications, explainability is not optional.
What is your approach to model risk management?
We sluiten aan bij EBA Guidelines en SR 11-7-principes: scheiding tussen development, validation en use, een onafhankelijk validatie-rapport, periodieke herproef-triggers en een werkend governance-forum dat sign-off doet voor productie. Voor banken die nog geen volgroeid framework hebben, helpen we met het opzetten ervan parallel aan het eerste model.
Do you build bespoke solutions or roll out a platform?
We build bespoke solutions rather than push a proprietary platform. That means choosing open components (Python, MLflow, dbt, Kafka) and the cloud stack that fits your DORA and data residency choices. No vendor lock-in to a proprietary black box, but an architecture your own team can take forward.
Ready for an AI project that gets through risk and compliance?
We build AI for banks, asset managers, fintech partners and insurers, using the AI Act, DNB/AFM, EBA, EIOPA and DORA frameworks as a starting point rather than a final check. Schedule a conversation for a concrete first exploration, or see our related services in fintech app development and AI in asset management.
Schedule a conversation