Most conversations about AI governance in banking start with frameworks, policy documents, and the question of which committee should own it. These things matter. But the question that determines whether your AI governance programme actually works, as opposed to whether it just looks good on paper, is a technology question, not a policy question. 

The question really is: does your core banking infrastructure make AI governance possible, or does it make it performative? 

AI compliance failures cost organisations $4.4 billion globally in 2025, global AML fines totalled $4.6 billion in 2024 alone, regulatory fines issued to financial institutions increased by 417% in H1 2025 compared to the same period in 2024, and reputational damage from AI misuse drives 15 to 20% customer churn annually.  

Many of these institutions had governance frameworks, what they didn’t have was the infrastructure to make those frameworks real. 

This article sets out what AI governance requires at the technology level; it highlights the specific infrastructure decisions that determine whether a CRO or CCO can genuinely answer a regulator’s questions, versus spending three weeks reconstructing what happened and hoping the answer is defensible.

The cost of getting AI governance wrong 

Before getting into the technology, it is worth being precise about what “getting AI governance wrong” costs, because the costs are not evenly distributed. 

Direct regulatory fines 

One company was fined $80 million by 48 state regulators for inadequate AML monitoring systems while another faced a $3.09 billion penalty for governance failures that enabled financial crime. In our markets, the CBN’s increasing enforcement activity, the BSP’s accelerating requirements, and the OJK’s formalised AI governance framework all signal that the trajectory is toward more enforcement, not less. 

Operational disruption 

Non-compliance forces AI system suspension, disrupting 75% of operations for affected institutions. When a regulator requires you to suspend an AI system such as a fraud detection model, a credit scoring engine, or an automated AML workflow, the operational impact extends far beyond the fine itself. Manual processes that replaced automated ones create backlogs, decisions that were made in seconds now take days, and customers are bound to experience the difference. 

Reputational damage  

This is the hardest to quantify and the slowest to recover from. 15 to 20% customer churn annually follows AI misuse incidents. In markets where digital banking trust is still being established, a publicly visible AI governance failure damages not just the institution but the broader ecosystem of trust that digital banking depends on. 

The model drift problem 

The European Central Bank has already fined major banks specifically for using outdated anti-money laundering models, establishing that "model drift" is no longer an acceptable defence. Regulators now expect transparent, continuous model governance, not point-in-time validation.  

What regulators are truly asking for and what their requests require technically  

The OJK’s AI Governance guidelines for Indonesian banks, the CBN’s Baseline Standards for Automated AML Solutions, and the BSP’s evolving AI expectations in the Philippines all converge on the same set of requirements. Understanding what these requirements demand technically is where most compliance programmes fall short. 

Requirement 1: Explainability of transactions 

Every market’s regulator now expects that when an AI system makes a decision affecting a customer, such as approving or declining credit, flagging a transaction, or restricting an account, the institution must be able to then explain that decision in plain terms.  

What this requires technically: Explainable AI requires that the model’s input features, weightings, and decisioning are documented and interpretable from the start. It also requires that, when a decision is made, the specific inputs that drove it are logged alongside the output so that six months later, when a regulator or customer asks why an account was restricted, you can reconstruct that specific decision from stored data rather than from inference. 

This means your AI models need to write decision logs to a storage layer that is queryable, complete, and retained for the required period. If your core banking system doesn’t maintain these logs, or if they exist in a separate system that isn’t connected to the customer record, explainability becomes a manual reconstruction exercise every time it’s needed and manual reconstruction is not what regulators accept as evidence of control. 

Requirement 2: Continuous monitoring, not periodic review 

Regulators are now asking whether you are monitoring continuously for performance degradation, bias drift, and unexpected behaviour. 

What this requires technically: Continuous monitoring requires a data pipeline that feeds current transaction and decision data to your monitoring infrastructure on an ongoing basis. It requires baseline performance benchmarks established at deployment, and automated alerting when performance deviates from those benchmarks. It requires that your monitoring infrastructure can access the same data your models use, in real time, without depending on the production core to service those queries. 

This is precisely the use case for a governed, off-core data replica: a continuously synced copy of your production database that your risk and compliance teams can query freely, without creating load on the live system. 

Requirement 3: Human oversight and escalation paths 

Most regulatory frameworks covering AI in banking require that automated decisions affecting customers can be escalated to human review. An AI system cannot be the final word, particularly for high-stakes decisions. An AI-declined credit application must be challengeable and an AI-flagged account restriction model must be reviewable by a person with the authority and data access to overturn it. 

What this requires technically: Escalation paths are a data access requirement. The person reviewing an escalated AI decision needs to see, immediately and completely, the customer’s full history: every transaction, every channel interaction, every previous decision, and the specific inputs that drove the AI's output on this occasion. If that data access takes hours to assemble, or requires a data export request, the escalation path exists on paper but not in practice. 

The technology requirement is a core that treats all customer data across all products and channels as a unified record, and a data layer that makes that record accessible to the right people in the right timeframe. 

Requirement 4: Audit trails that are continuous 

The distinction between a continuous audit log and a reconstructed report is one of the most practically important in AI governance. 

A continuous audit log records every event as it happens, with a timestamp, in a form that cannot be altered retroactively. A reconstructed report is what you produce when a regulator asks for something your systems don’t generate automatically. 

Regulators know the difference.  

What this requires technically: Genuinely cloud-native cores process and log transactions as events; every action is recorded as it occurs, accessible in real time, and immutable. Cores that batch-process can produce reports, but they cannot produce continuous logs of the same completeness. 

The five technology questions every CRO and CCO should be asking 

Given the above, here are the specific questions that determine whether your AI governance programme is real or performative. 

1. When an AI system makes a credit or fraud decision, are the specific inputs and outputs of that decision logged at transaction level and can we retrieve that log for any individual decision within one hour?  

2. Do our AI monitoring tools access model performance data in real time or do they run on weekly or monthly extracts? 

3. When a compliance officer needs to review a customer’s complete history, how long does that take and how many systems does it involve? 

4. Can we demonstrate continuous model monitoring to a regulator as a live view of model performance over time? 

5. If we needed to suspend an AI system today because a regulator required it, or because we detected unexpected behaviour, what would happen operationally and do we have documented fallback procedures? 

75% of operations are disrupted when AI systems are suspended without adequate fallback planning. The question of what happens when AI goes offline is as important as the question of what it does when it’s running. 

What good AI governance infrastructure really looks like  

A strong AI governance posture in emerging markets requires a specific infrastructure profile. 

A governed, off-core data replica 

A secure, read-only copy of the production database, continuously synced, accessible to compliance and risk teams without touching the live system. This is the foundation for continuous monitoring, for rapid investigation, and for the audit trail completeness that regulators expect. Oradian’s Database Access is built specifically for this purpose, with full-fidelity data, continuously updated, stored on the institution’s own infrastructure. 

Event-driven core architecture 

Every transaction and every AI decision is logged as it occurs, not reconstructed from batch exports. This is what makes continuous audit trails technically achievable rather than aspirationally described. It is also what makes the 30-minute fraud response requirement the CBN issued in January 2026 practically achievable. 

Configurable decision logic with version control 

When a model needs to be updated because of regulatory changes, or because of detected drift, or maybe because of new fraud patterns, you must have the ability to make that change quickly and to document exactly what changed, when, and why. Institutions dependent on vendor release cycles for model updates cannot maintain the governance cadence that regulators now expect. 

Documented integration between AI systems and the core 

The AI fraud model, the credit scoring engine, and the AML monitoring system all need to be connected to the core in a way that is documented, auditable, and explainable. Black-box third-party AI tools that produce decisions the institution cannot interrogate are a governance liability, regardless of how accurate they are.

Oradian: Your key to achieving AI governance  

For more on the data and infrastructure foundations behind AI governance in dynamic markets, read The Digital-First Bank’s Guide to AI in 2026. 

To understand how the CBN, BSP, and OJK requirements translate into specific compliance infrastructure decisions, check out The Regulation Playbook for Digital Banks in 2026. 

If you’re ready to start truly leveraging AI at your bank or lending institution, speak to vanda.jirasek@oradian.com to book in a demo.