AI in Compliance Is an Architecture Decision — It's Not a Vendor Pick

When a bank's Chief Technology Officer and Chief Compliance Officer sit down to evaluate AI tools for compliance operations, they usually frame the question as a vendor selection problem. Which platform is best? What features does each vendor offer? How do pricing models compare?

This framing overlooks the actual decision being made. Selecting an AI compliance vendor is one of the most significant architectural decisions a bank's compliance and technology teams will face. It shapes which data the system touches, how decisions get made, where humans stay in control, how you audit outcomes, and what happens when the system is wrong. These questions go beyond vendor comparison—they're structural design questions.

Getting the architecture right matters far more than picking the "best" vendor. Most banks should buy instead of build. But buying without understanding what you're actually getting tends to produce buyer's remorse.

The Vendor Selection Framing Is Incomplete

When evaluators approach AI tool selection as a vendor comparison, they tend to focus on feature parity and cost. This vendor has better alert filtering. This vendor has more case templates. This vendor integrates with your case management system more directly. Price point matters. Reference customers matter.

These questions matter, but they're secondary to much deeper architectural decisions. You can have a well-designed AI system from a less capable vendor, or a poorly integrated feature-rich system from a capable vendor. The features don't tell you which you're getting.

The questions that actually shape outcomes are typically not part of vendor selection discussions:

What data does the system need access to, and what doesn't it need? This determines scope. Does the system touch transaction data, customer data, external lookups, case notes? Does it modify data or only read it? The broader the data access, the broader the audit and risk surface.
How does it integrate with your existing decision workflow? Does it replace human decision-making or augment it? Where exactly in your process does the system engage? What happens to cases the system can't resolve?
Where does human judgment stay in the loop, and why? Every system needs humans somewhere. Are humans reviewing AI outputs before filing? Approving escalations? Overriding decisions? The architecture of human oversight determines whether you're building an auditable process.
How are decisions explained and audited? Can you trace why the system made a specific decision on a specific case? Can you show an examiner exactly what factors were considered and why? Black-box systems that deliver outputs without audit trails are high-risk regardless of accuracy.
What happens when the system makes a mistake? How do you catch errors? How do you correct them? Is there a system for identifying patterns of failure? If the system misses 5% of true positives, how do you find those cases?

Vendors will answer these questions if pressed. But they're not part of standard vendor demos. They don't show up in feature comparison matrices. CTOs and CCOs rarely ask them because the vendor selection frame doesn't prompt those questions.

Data Access Questions Often Get Avoided

One of the most consequential architectural decisions is what data the system touches. Most banks underspecify this.

Some AI compliance systems need read-only access to transaction data. Some need access to customer data, beneficial ownership information, and account metadata. Some need real-time access; others work on batch feeds. Some systems need to write flags or scores back to your case management system; others only deliver recommendations humans enter manually.

The broader the data access, the broader your compliance obligations around that system. If the system has access to customer personal information, you have data governance requirements. If it modifies case data, you have audit trail requirements. If it produces decisions without explanation, you have regulatory risk.

Good architecture specifies: This system needs access to transactions and basic account metadata. It does not need customer personal information. It reads from your system; it doesn't write to it. Recommendations go through human review before any case action is taken.

Bad architecture says: The system will need access to all your data so it can work optimally. Trust that we've thought about the risk.

Examiners ask about data access. They want to know what systems touch what information and why. If the architecture is overspecified—the system has broader access than necessary—you're creating unnecessary audit surface.

Integration Architecture Determines Operational Success

Many AI compliance tool implementations struggle because the vendor's architecture doesn't align with the bank's case management and workflow systems. The tool works in isolation but produces friction when it meets the actual compliance process.

Questions you should be asking:

Does the system require a specific case management platform, or can it integrate with your existing system?
If it requires an existing system, what work do you need to do to make that integration real? Is it API-based? Batch files? Manual data entry?
If cases are going to flow through both the AI system and your case management system, which system of record matters? How do they stay in sync?
When your investigators work on a case, do they work inside the vendor's system or yours? If it's the vendor's system, what does that mean for your audit trail and compliance documentation?

Poor integration creates bottlenecks. Your investigators end up doing work twice—once in the AI system to get the recommendation, once in your case management system to document the decision. Or case data gets entered once and never updated as investigation unfolds. Or the systems disagree about what the current state of a case is.

Good architecture specifies that the AI system is a component of your workflow, not a replacement for it. Your investigators work primarily in your existing systems. The AI system feeds recommendations into that workflow at specific points. Cases progress through your standard process with AI assistance, not through a separate AI system.

Human Oversight Architecture Determines Auditability

Every AI system that matters has humans making final decisions somewhere. The question is where, and whether those decisions are auditable.

Some vendors pitch systems that make decisions autonomously—automatically file SARs, automatically close low-risk alerts, automatically escalate cases meeting certain thresholds. This is fast and efficient, but also high-risk from an examination perspective.

When an examiner asks "who decided to file this SAR?" and the answer is "the AI system decided and we didn't override it," that creates a problem. AI systems cannot take responsibility for decisions; only humans can. If you can't identify a specific human who reviewed and approved a SAR filing, you have an audit gap.

Good architecture puts humans explicitly in decisions that matter. SAR filings? A human approves. Escalation decisions on high-stakes cases? A human confirms. The AI system generates a recommendation and shows its work; a person makes the decision and owns it.

This slows things down slightly relative to fully autonomous AI. But it preserves auditability, keeps human judgment in the right place, and aligns with how examiners evaluate compliance.

Explainability and Audit Trail Matter More Than Raw Accuracy

If a vendor tells you their system achieves 95% accuracy on alert classification, ask: accurate at what? Predicting which alerts are false positives? Predicting which cases require SAR filing?

More importantly: if the system gets 5% wrong, how do you find those cases? And if an examiner asks you to explain a specific decision, can you do it?

An explainable system with 92% accuracy will serve you better than a black box with 97% accuracy. Examiners will ask you to justify decisions, and if you cannot, the overall accuracy becomes secondary to the audit failure.

Good architecture specifies: This system will explain what factors influenced each decision. You can pull any case and see what the system observed, what factors mattered, and how it reached its recommendation. This creates an audit trail.

Vendor red flags:

Black-box decisioning. "The system works but we can't really explain how" is a regulatory red flag.
No audit trail. If you can't produce a record of what the system saw and why it decided what it did, you can't defend the decision to an examiner.
Can't explain edge cases. Ask the vendor: what happens on a case that's borderline? Can you show me how the system handles ambiguous situations? If they can't, the system probably isn't handling them well.
No confidence scores or uncertainty quantification. Good systems tell you when they're uncertain. Bad systems pretend to know things they don't.

The Build vs. Buy Decision

Before diving into vendor evaluation, banks often wonder: should we build this ourselves?

For most banks, the answer should be to buy rather than build. Creating AI compliance systems requires data science expertise, ongoing model maintenance, compliance knowledge, and software engineering depth—most banks lack that combination in-house. Building also commits you to perpetual maintenance and support that diverts your team's attention from compliance strategy.

But buying doesn't mean accepting whatever a vendor offers. It means finding a vendor whose architecture aligns with how you want your compliance function to operate. This is why the architectural questions matter more than the feature comparison.

A few banks with substantial data science and compliance teams do build. When they do well, the critical difference is that they treat the AI system as a tool that augments their existing compliance process, not a replacement for it. They keep humans in the right decisions. They maintain rigorous audit trails. They build systems that can be explained.

What a Good Evaluation Process Looks Like

If you're evaluating AI compliance systems, here's how to get past vendor positioning and into architecture:

Start with your process, not the vendor's. Map how SAR decisions actually get made in your institution. Who touches a case? At what points? What information drives decisions? Then ask: where could an AI system help without disrupting this process?
Specify data flows explicitly. Document: this system needs access to X data. It doesn't need Y data. It reads from our systems; it doesn't write to them. Get the vendor to confirm their system can operate within those constraints.
Evaluate explainability on real cases. Don't ask for a demo on the vendor's sample data. Provide a handful of your own edge cases and ask the vendor how their system would handle them. Can they walk you through the reasoning? Can they show audit trails?
Talk to operators, not just managers. Reference customers' investigators should tell you: does this system make my job easier or harder? Do I trust the recommendations? Can I defend them to an examiner?
War-game failure scenarios. Ask the vendor: what if your system starts making bad decisions? How would we detect it? How would we fix it? How would we remediate historical cases?
Understand integration dependencies. If the vendor's system requires specific case management platforms or data structures, understand that cost upfront. Integration friction compounds over time.

Why This Matters

Banks that approach AI compliance tool selection as pure vendor comparison often end up with systems that work technically but create operational friction, audit challenges, or insufficient integration with existing workflows. They optimized for features rather than architecture.

Banks that approach it as an architectural decision—specifying what data the system needs, how it integrates with existing workflows, where humans stay in control, how decisions get audited—end up with systems that improve compliance outcomes without creating new risks.

The difference usually comes down to clarity. The best outcomes come from banks that think clearly about what they're actually building when they deploy AI in their compliance function.

That's an architecture problem, not a vendor problem. Get the architecture right, and vendor selection becomes straightforward.