Policy engine: What it is and how it keeps compliance current

In compliance, mistakes can cost millions and end careers. A head of compliance and money laundering officer was recently fined an estimated €69,500 for failing to carry out the responsibilities of his role. The penalty came from the Central Bank of the UAE which also fined the foreign bank branch that employed him roughly €4.6 million for significant and repeated failures in its anti-money laundering (AML) and sanctions compliance framework.

European regulation also makes leaders personally accountable for AML failures. Under the EU’s Sixth Anti-Money Laundering Directive (AMLD6), senior leaders responsible for serious breaches can face personal penalties. 

This puts pressure on compliance leaders to ensure the policies they set are being followed as intended. Compliance officers spend their time translating vague regulations into policy documents, but a written policy isn’t enough. Turning policy into code builds those rules into the system so they can be applied consistently, even as business conditions or regulations change.

Traditional tools handle onboarding, reboarding, and periodic reviews as separate workflows. If documents expire or ownership changes, a new workflow begins instead of updating the existing assessment.

A policy engine continuously checks customer relationships for nonconformities and figures out which remediations are needed to get back on track. Business identity stays current as each assessment builds on what the system already knows.

A policy engine is like Google Maps

To illustrate how the policy engine works, let’s take a simple example of driving to the supermarket.

A workflow-based system is like following a printed map with a fixed set of directions: go straight, turn left, then take the second right. If a road is closed, those directions no longer work. You might have to return to where you started or manually find a new route.

A policy engine works more like Google Maps. You’ve defined the destination — or what good looks like — but if traffic builds up or a road closes, the system automatically recalculates a better path, no matter how many detours you come across.

Why workflows break down

An executive from a leading global fintech told us that every regulatory change forces the team into more than 6 months of engineering work to rebuild compliant onboarding workflows. A new regulation arrives, stakeholders align, teams agree on requirements, and the rebuild begins.

Until the rebuild is complete, compliance teams may have to manually check new requirements, as well as add review steps and manage exceptions outside the existing system. The next time a rule changes, they have to do it all again. This approach doesn’t scale, especially for financial institutions handling large compliance volumes.

Workflow-based onboarding systems are built around predefined workflows. Every customer follows a strict sequence of tasks, such as:

• collect documents A – E

• check for sanctions

• review media coverage

• check for politically exposed person (PEP) status

• update risk

Those workflows reflect the policies, regulations, and business requirements that existed at the moment they were designed. Automating these workflows can make them faster to build and easier to modify, but it doesn’t solve the underlying limitation. Nonconformity is difficult to detect when using workflows, yet for policy engines it's business as usual. A single requirement change can trigger updates across multiple workflows before it can be consistently applied. 

In the meantime, cases may be assessed against outdated requirements, increasing the risk of missed controls and compliance failures.

Build compliance once, adapt continuously

Duna’s policy engine starts by defining what a compliant business looks like. Instead of trying to define every possible case up front, the system keeps checking the policy against new information. As regulations change, documents expire, or ownership shifts, the system can adjust the next step without requiring engineering to rebuild the process.

Regulatory updates that used to take six months turn into automated deployments that happen in hours, such as geographic risk signal updates. Terms and agreements can be rolled out instantly. With compliance running in the background, teams can keep their focus on the core business.

Duna customers are closing cases 16.3x faster using automated assessments, real-time risk signals, and auto-generated tasks.

How the policy engine works

The policy engine in Duna’s onboarding and compliance platform combines three core concepts: policy as code, evidence-based reasoning, and continuous evaluation.

Policy as code: Most policies were written for people and largely describe manual processes. When those requirements are translated into code, they define the conditions the system evaluates and the actions it should take when those conditions are met.

For example:

• If revenue > x, then request financial documents

• If Ultimate Beneficial Owner (UBO) ownership exceeds 25%, identify and verify the owner

• If legal representative is based in a country other than the company’s place of incorporation, then increase Anti-Money Laundering (AML) risk.

Because the same policy is applied consistently, the same evidence leads to the same outcome. Every decision can be traced back to the policy and data that produced it, creating the consistency and explainability that compliance teams and regulators require. Traditional generative AI on its own can’t reliably give you the same decision again from the same policy and evidence.

Evidence-based reasoning: Duna’s platform stores business identity as individual pieces of evidence, such as the owner’s name, company website, expected annual revenue, and company address. Each piece of evidence includes when it was collected and where it came from, creating a complete audit trail.

During onboarding or reboarding, evidence is collected through APIs, customer submissions, registries, and other data sources. This evidence shows the current state of the business and gives the policy engine the information it needs to assess whether the policy requirements have been met.

The policy engine sets the rules and guardrails for AI agents to collect and evaluate additional evidence where human work or judgment was previously required.

Because the evidence is stored separately from the policy, organizations can apply updated requirements to existing customers without collecting the same information again or asking engineering teams to rebuild the system.

Continuous evaluation: Policy and evidence can be re-evaluated whenever circumstances change. A new regulation or sanctions update can trigger another assessment using the latest policy and available evidence. That keeps the company working from the most current information throughout the customer lifecycle, instead of relying on an old onboarding decision.

Example: Tax ID using the policy engine

A tax ID policy for a bank or fintech might look like this: Customer must have, if available, a valid VAT number or local tax ID to be approved for a domestic contract.

This is what “good” looks like. It’s quite simple from a user and customer perspective. But under the hood, the policy engine works through a lot of complexity:

• Translate the requirement into a local requirement (collect BTW number or USt-IDNr.)

• Collect tax ID from registry or website instead of asking for it

• Provide local example and validation logic to frontend

• Offer escape hatch dependent on legal form if no VAT number is expected to exist

• Automatically handle verification against VIES

• If VIES is offline, trigger async verification before review

• If VIES does return a company name, match against registered name - for mismatch, alert

•  If User country = connection country, allow for local tax ID instead

If this policy changes, compliance teams only have to change the definition. The policy engine automatically rearranges all of the hidden complexity to fit the new policy, allowing analysts more time to work on high-risk cases.

What regulators actually reward

Compliance has traditionally been designed for human intervention focused on processes and sequential steps — not for machines. A policy engine changes the approach from humans completing a workflow to AI maintaining a compliant state.

Regulators care about effective controls and explainable outcomes. A policy engine is designed to deliver both.

See how Duna helps banks and fintechs turn compliance policy into a continuously managed customer lifecycle. Get in touch.