Banks have spent the past few years hearing that AI will cut false positives, speed up investigations, and eventually close alerts on its own. Aishwarya Kothapally has spent those same years testing that promise against production data. As First Vice President of Financial Crimes Compliance at BHI Bank in New York, she oversees the models, tuning decisions, and governance frameworks that determine which transactions get a second look. Her recent ACAMS piece on regulator-ready model governance drew on more than a decade of work across AML, sanctions, transaction monitoring, and model risk.
In this conversation with AI Journal, she explains what documentation a compliance team should already have before an examiner asks, why an alert reduction figure on its own tells you very little, and what would need to be true before she would let an agent close a case without a human in the loop. She also weighs in on vendor black boxes, diverging regulatory regimes, and which parts of an analyst’s job she expects to survive automation.
You’ve described “regulator-ready” model governance in your ACAMS piece. In practice, what does a compliance team need to have on paper before an examiner asks about a detection model?
The starting point is being able to tell the complete story of the model: what is the model designed to detect, why was it implemented, what data does it use, what are the key assumptions and limitations, who owns it, and how is its performance being monitored? I would also expect to have the validation and testing evidence, change history, tuning decisions, approvals, and ongoing performance monitoring readily available. One thing I have learned is that documentation shouldn’t be created because an examination is coming. If a threshold or methodology was changed six months ago, the institution should already be able to explain why it changed, who approved it, what testing supported the change, and what impact it had.
That, to me, is what regulator-ready really means. Ultimately, one should be able to reconstruct the life of the model from the documentation.
Where has AI delivered on reducing false positives in transaction monitoring, and where have the results fallen short of the sales pitch?
AI can be very useful in areas like alert prioritization, identifying patterns across larger amounts of data, and helping distinguish activity that deserves investigation from repetitive activity that may have a reasonable explanation.
But I am cautious about framing success simply as ‘we reduced false positives by X percent.’ Reducing alerts is easy if you loosen the detection criteria. The real question is whether you reduced unnecessary alerts without reducing your ability to identify meaningful risk.
That is where some of the sales pitch can get ahead of reality. A model may perform very well in a controlled test, but production data changes, customer behavior changes, and investigators may use the output differently than expected. So, I look at false-positive reduction together with detection effectiveness, coverage, false negatives, and investigator outcomes.
For example, in one transaction monitoring tuning exercise I worked on, the initial results suggested that a threshold adjustment could significantly reduce the number of alerts. But when we looked beyond the overall alert reduction and reviewed the underlying transactions, we found that some of the activity being removed still represented behavior we wanted the scenario to capture. So rather than looking at the reduction percentage alone, we went back to the transaction level, tested different threshold options, reviewed the resulting population, and evaluated the impact on risk coverage. That experience reinforced for me that reducing false positives is not the same thing as improving a monitoring program. You have to understand what you are removing and why.
Agentic AI implies systems that take actions, not just flag them. What would need to be true, technically and organizationally, before you’d let an agent close an alert without a human?
I would set a very high bar for that.
Before allowing autonomous closure, I would want evidence that the agent performs consistently on a clearly defined population, that the underlying data is complete and reliable, and that we can reconstruct exactly what information it considered and why it reached its decision. I would also want clear escalation criteria and ongoing monitoring. If the agent encounters something outside the conditions it was tested on, it should know when to stop and send the case to a human.
Organizationally, ownership is just as important. Someone has to be accountable for the decision framework and for monitoring what the agent is doing. Personally, I would start with a narrow, lower-risk population and human review. Autonomy should be earned through demonstrated performance rather than granted at implementation. I wouldn’t go from human investigation to autonomous closure in one step.
How do you decide when a monitoring model needs retuning, and what signals tell you a model is drifting?
I don’t think returning should happen simply because the calendar says it is time. Periodic review is important, but the data should tell you when something has materially changed. I would look at alert volumes and disposition trends, changes in false-positive rates, scenario productivity, customer or transaction population changes, changes in the underlying data, and whether investigators are repeatedly seeing the same types of non-productive alerts.You also have to look at what the model may be missing, not just what it is generating.
And every tuning exercise should come back to the original purpose of the scenario. If the model’s output has moved away from the risk it was designed to identify, that is a much stronger indication that something needs attention.
I’ve also seen situations where alert volumes themselves weren’t necessarily the problem, but transaction-level testing showed that the scenario logic was producing results differently from what the business requirement intended. That is why I don’t rely on a single performance metric. I like to go back to sample transactions and trace the logic from the underlying data through the alert outcome. Sometimes that tells you much more than an aggregate alert rate.
Compliance, data, and technology teams often speak different languages. What has worked for you in getting them to build detection programs together?
One thing that has worked for me is translating the compliance requirement into something technical teams can actually build and test.
Compliance may say, ‘We need to identify this type of suspicious behavior.’ Technology needs to know what that means in terms of data fields, transaction types, lookback periods, thresholds, exclusions and expected outputs. I have found that bringing those teams together early is much more effective than compliance writing requirements and handing them over to technology.
One approach that has worked well for me is using actual transaction examples during requirements and testing discussions. Instead of saying only that a scenario should identify a particular pattern, I’ll take sample transactions and walk the teams through this one should alert, this one should not, and here is why. I’ve found that this often uncovers differences in how compliance and technology interpreted the requirement before those differences make it into production.
Vendors bring black-box models to banks all the time. How do you evaluate explainability, and where do you draw the line on what you’ll accept?
I don’t believe that ‘proprietary’ can be the end of the conversation. I don’t necessarily need every line of a vendor’s code, but the institution does need enough information to understand how the model works, what data drives the outcome, what its limitations are, how performance is measured, and how a particular decision can be explained.
If the bank receives an alert or risk score but cannot meaningfully explain why it was generated, that becomes difficult from both a governance and validation perspective. My line would be whether we have enough transparency to independently challenge the model, test its performance and explain its use to an examiner. If we can’t do those things, saying ‘the vendor owns the algorithm’ solves the governance problem. In other words, you can outsource the technology, but you can’t outsource accountability.
US regulators, the EU’s AMLD6, and the UK’s FCA all approach AI in financial crime a little differently. What do you see as the meaningful differences, and which direction is the field moving?
There are differences in the regulatory frameworks, but the direction of travel is actually quite consistent. Regulators want institutions to innovate, but they also want accountability, explainability, effective oversight and evidence that the technology is doing what the institution says it is doing. The terminology and regulatory mechanisms may differ across jurisdictions, but the practical expectation is converging understand the technology, understand its limitations, document the decisions around it, test it and maintain meaningful human oversight where the risk warrants it. So, for a global institution, I would focus on building a governance framework strong enough to meet those common principles rather than designing completely separate AI governance programs for every jurisdiction.
What’s a common mistake you see institutions make when they adopt AI for AML, and what would you tell a compliance head who’s about to start?
One mistake is starting with the technology instead of the problem. Sometimes the conversation begins with, ‘We want to use AI,’ when it should begin with, ‘What problem are we trying to solve?’ I would start with a clearly defined use case where you already understand the current process and have a way to measure whether the new approach is actually better. Then establish the governance before scaling it: ownership, testing, validation, human oversight, documentation and monitoring. I would rather see an institution successfully implement AI for one narrow use case and understand it extremely well than deploy it across five areas without being able to demonstrate that it works. Hence, I would start with the problem, not with AI.
Looking two or three years out, what part of a financial crime analyst’s job do you expect will change the most, and what will stay stubbornly human?
The biggest change is likely to be in information gathering and the first stages of investigation.
Analysts spend a lot of time pulling together transaction history, customer information, prior alerts and other data before they can actually exercise judgment. AI can potentially do much more of that work – organizing information, identifying relevant patterns, prioritizing alerts and even preparing an initial case summary. What I think will remain human for much longer is judgment in ambiguous situations. Financial crime rarely gives you perfectly clean answers. Understanding context, challenging an unusual explanation, deciding whether activity is genuinely suspicious and taking accountability for consequential decisions are very different from summarizing data. So, I don’t necessarily see the analyst disappearing. I see the analyst spending less time assembling information and more time making decisions.
