AML and KYC Compliance in Banking: Why Your Decision Logic Belongs in a Business Rules Engine

Key takeaways

• AML and KYC programs run on hundreds of decisions: which ID checks apply, how risky a customer is, when enhanced due diligence starts, which alerts go to which analyst.
• When that logic is hard-coded or spread across spreadsheets, a bank cannot show examiners which rule produced which outcome - or change a threshold quickly when the rules change.
• A business rules engine keeps this logic in one place, versioned and tested, with an audit trail for every decision.
• US requirements are moving toward documented, risk-based programs: FinCEN’s April 2026 proposal would tie program effectiveness to a documented risk assessment. In the EU, the AML Regulation applies from July 10, 2027.
• A rules engine does not replace identity verification, sanctions screening or transaction monitoring tools. It is the decision layer that connects them.

What is a business rules engine for AML and KYC?

A business rules engine for AML and KYC is software that runs a bank’s compliance decision logic - customer due diligence levels, risk ratings, escalation triggers, alert routing - outside the core application code. Compliance teams define and test the rules; the engine executes them in real time and records every decision.

The idea is simple: the rules that decide how a bank treats a customer should be as visible and controllable as the policy they come from. For the fundamentals of how rules engines work, see What Is a Rules Engine?.

What decisions does an AML and KYC program actually make?

Most AML discussions focus on detection. In practice, a program makes many smaller decisions every day, and each one needs a documented reason:

Some of these follow fixed regulatory values - for example, a Currency Transaction Report for cash transactions over $10,000 in a business day, or a SAR filed within 30 calendar days of initial detection (extendable to 60 if no suspect is identified). Most are the bank’s own risk-based choices. Both kinds need to be applied consistently and explained on request.

Which regulations shape AML and KYC decision logic in 2026?

In the United States, the Bank Secrecy Act sets the baseline. Banks must run a Customer Identification Program and follow FinCEN’s Customer Due Diligence Rule, which has required the identification and verification of beneficial owners of legal entity customers since May 2018.

Three 2026 changes matter for decision logic:

• Beneficial ownership relief (February 2026). FinCEN’s exceptive relief order of February 13, 2026 means banks no longer need to re-verify beneficial owners each time an existing legal entity customer opens a new account. They must still do it at the first account, when facts call earlier information into question, and when their risk-based procedures say so (Mintz, February 2026). That is a new branch in onboarding logic, not a removal of it.

• Proposed reform of AML/CFT programs (April 2026). On April 7, 2026, FinCEN proposed a rule that would require institutions to “identify, assess, and document” money laundering and terrorist financing risks, and would let them direct more resources to higher-risk customers and less to lower-risk ones, provided that choice follows the risk assessment. The proposal names AI and other advanced monitoring tools as a way to show program effectiveness. It is still a proposal; the banking agencies issued parallel proposals, and the compliance period would be 12 months after a final rule (Mayer Brown, April 2026; Federal Register, July 9, 2026).

• Corporate Transparency Act exemptions. Under FinCEN’s August 2026 final rule, US companies are exempt from beneficial ownership reporting to FinCEN (BDO, 2026). For banks, that puts even more weight on their own CDD data and rules.

The direction is clear: examiners will ask less “did you tick every box?” and more “show us how your risk assessment drives your controls.” That is a question about decision logic.

In the European Union, the Anti-Money Laundering Regulation (EU) 2024/1624 applies directly in all member states from July 10, 2027. It defines simplified, standard and enhanced due diligence with specific entry conditions, keeps a 25% baseline threshold for beneficial ownership, and caps cash payments for goods and services at €10,000. The new EU authority, AMLA, begins direct supervision of about 40 large, high-risk institutions from January 1, 2028 (Marble, 2026). Banks operating on both sides of the Atlantic will run two rule sets that overlap but do not match.

Why does hard-coded AML logic become a compliance risk?

Because a bank has to prove what its controls did, not only what its policy says. When due diligence rules live in core banking code, onboarding scripts and analyst spreadsheets, three problems appear:

• Nobody can see the full logic. Compliance writes the policy, IT implements it, and over time the two drift apart. The bank cannot show examiners which version of a rule applied to a given customer on a given date.

• Changes are slow. A new high-risk jurisdiction, a regulator’s guidance or a new product means a development ticket, a release cycle and a regression test. Meanwhile, analysts apply the change by hand.

• Coverage gaps stay hidden. If a product or channel is not wired into the rules, its customers and transactions are not assessed at all - and no report says so.

The last point is not theoretical. In October 2024, TD Bank agreed to pay about $3 billion to resolve BSA/AML violations, including a record $1.3 billion to FinCEN. Authorities found that about 80% of its transactions were not screened for suspicious activity and more than 5 million customer accounts never received a risk rating (Lowenstein Sandler, October 2024). The lesson for any bank: you need to know, and be able to prove, which rules run against which customers and transactions.

Where does a rules engine fit in the AML and KYC stack?

A rules engine is not an AML suite. It works alongside the tools a bank already has:

The decision layer is where the bank’sown risk appetite lives. Screening tells you there is a possible match; therules decide what that match means for this customer. A monitoring systemraises an alert; the rules decide which analyst sees it first and how fast.

Keeping this layer separate has anarchitectural benefit too. When a vendor changes, the bank’s rules stay inplace, and the bank does not have to rebuild its risk logic inside each newsystem.

What does a customer risk rating rule look like?

Here is a simplified decision tablefor customer risk rating at onboarding. In a rules engine, compliance analystsmaintain a table like this directly and test it before it goes live:

Every row has an owner, a version and a reason. When the bank changes its country risk list, the change goes through testing and approval, and every later decision references the new version.

How do business rules and machine learning work together in AML?

Machine learning is good at spotting patterns that fixed rules miss - unusual behavior within a peer group, networks of related accounts, alerts that are likely false positives. Rules are good at applying policy consistently and explaining why.

The working pattern in regulated institutions: the model scores, the rules decide, and both are logged. A model may return a risk score for a new customer; the rules turn that score into a due diligence level, apply hard limits the model cannot override (for example, sanctions matches or prohibited industries), and record the rule and model versions behind the outcome.

This setup helps with model governance. Your model risk management team validates the model; compliance owns the policy boundaries around it; and every decision can be reconstructed. It also fits the direction of the FinCEN proposal, which treats advanced monitoring tools as evidence of an effective program.

What do examiners and auditors expect from AML decision logic?

Whatever tools a bank uses, the same evidence comes up in exams and independent testing:

• Traceability. For any customer or alert, which rules applied, with which inputs and which result.
• Version history. What the rule looked like on a given date, who changed it and why.
• Testing evidence. How a threshold change was tested before release, including its effect on alert volumes.
• Separation of duties. The person who writes a rule is not the only person who approves it.
• Rollback. A clear way back to the previous version if a change causes problems.
• Alignment with the risk assessment. A visible link between identified risks and the controls that address them.

A business rules engine produces most of this evidence as a side effect of normal work, instead of as a separate documentation project before each exam.

How does Higson support AML and KYC decisioning?

Higson is a business rules engine built by Decerto. It started in insurance, where product, underwriting and claims rules face the same audit demands as banking compliance, and it runs decision logic for financial services firms. In an AML and KYC setup, Higson is the decision layer described above.

• Decision tables that compliance teams maintain. Risk rating matrices, CDD triggers, country and industry lists, and review cycles live in tables that business users edit and test in Higson Studio. Lists prepared in Excel are imported through CSV.
• Testing before production. The tester and mass tester run a rule change against sample or historical cases, so the team can see how many customers would move to a different risk rating before the change goes live.
• Versioning, audit trail and granular permissions. Every change is versioned with rollback. Higson 4.3 LTS adds role-based permissions at the level of business domains, sessions and operations, with a full audit trail - so analysts can propose changes, and only designated approvers can publish them.
• Your models inside the rules. Higson’s ONNX runtime (since version 4.2) runs machine learning models inside rule execution. Your data science team keeps its models; Higson applies the policy limits around them.
• Real-time performance. Rule execution takes 0.23 ms per decision, with throughput of 9,000 requests/second - enough to rate a customer during digital onboarding or route alerts as they arrive.
• Performance insight. The Diagnostic Panel shows flamegraphs of rule calls, heatmaps of decision table rows and P50/P95/P99 percentiles, so teams can see which rules actually fire and how often.
• Deployment and security that fit banking IT. Cloud (AWS, Azure, GCP), on-premise Kubernetes or hybrid. The Runtime API supports JWT, SSL and basic authentication; Higson Studio supports SSO through Active Directory, SAML and CAS. Integration runs through REST API or Java SDK.
• AI-ready. An official MCP server with 50+ tools lets AI agents work with rules, and the AI Assistant in Higson Studio (beta) drafts functions in Groovy or Python and decision tables from natural-language descriptions.

This setup removes backlog from the IT queue: compliance owns the rules, and IT gets more time for architecture, data quality and integrations.

Financial services companies such as Fiserv and Notus Finanse use Higson for decision logic. In insurance, BNP Paribas Cardif consolidated claims rules from 5 product lines into one engine in 3 months, with one audit trail - the same pattern a bank needs when onboarding, CDD and alert rules are spread across products and channels.

How do you start moving AML and KYC rules into a rules engine?

Start with one decision that is frequent, well documented and visible to examiners:

1. Pick one decision. Customer risk rating at onboarding is a common first choice; CDD trigger logic or alert routing are good alternatives.
2. Document the current logic. Collect the rules from policy, code and spreadsheets. The gaps you find here are already a result.
3. Rebuild it as decision tables. Keep one table per decision, with named owners.
4. Test on historical data. Run past customers or alerts through the new rules and compare the outcomes with what the current system produced. Explain every difference.
5. Run in parallel, then switch. A short parallel run gives compliance and audit evidence that the new logic behaves as intended.
6. Plan the timeline realistically. Platform go-live with Higson typically takes 3–6 months. After that, adding a new decision area takes weeks, and a single rule change - such as a new high-risk country - takes hours.

See how your KYC rules would look in Higson

Bring one decision - customer risk rating, CDD triggers or alert routing - and we will show you how it would work in Higson, tested on your own sample data.

Book a 30-minute call

Download the Business Rules Engine Comparison Guide 2026

‍

Related articles

• What Is a Rules Engine?
• Enhancing Fraud Detection in Banking with Rule-Based Decision Engines
• Dynamic Pricing Engine for Financial Firms

Sources

1. FinCEN, „FinCEN Proposes Rule to Fundamentally Reform Financial Institution Programs…“ - https://www.fincen.gov/news/news-releases/fincen-proposes-rule-fundamentally-reform-financial-institution-programs
2. Mayer Brown, „Out with the Old, In with the Risk-Based…“ - https://www.mayerbrown.com/en/insights/publications/2026/04/out-with-the-old-in-with-the-risk-based-fincen-proposes-fundamental-reform-of-aml-cft-program-requirements
3. Federal Register, AML/CFT Programs (propozycja Fed) - https://www.federalregister.gov/documents/2026/07/09/2026-13919/anti-money-laundering-and-countering-the-financing-of-terrorism-programs
4. Mintz, „FinCEN Eases Beneficial Ownership Verification Requirements” - https://www.mintz.com/insights-center/viewpoints/54751/2026-02-18-fincen-eases-beneficial-ownership-verification
5. BDO, 2026 U.S. AML/CFT Regulatory Developments Tracker (CTA, GENIUS Act, CDD) - https://www.bdo.com/insights/advisory/2026-u-s-aml-cft-regulatory-developments-tracker
6. Lowenstein Sandler, „TD Bank to Pay Historic $3 Billion…“ - https://www.lowenstein.com/news-insights/publications/client-alerts/td-bank-to-pay-historic-3-billion-over-aml-compliance-violations-aml
7. Marble, „EU AMLR: what changes July 2027” - https://www.checkmarble.com/blog/eu-amlr