Why the Risk Engine Does Not Classify A Client As High Risk And Stop There

written by Manu
Risk Engine - KYC Agentic AI.

In this series, we are building an agentic KYC workflow for high-net-worth onboarding piece by piece.

I also built a working prototype in Python to demonstrate this architecture. You can find the link to the prototype here.

Agentic AI Workflow for KYC

In the previous post, we saw how the Signal Aggregator collects the findings from the individual agents and packages them into a clear case view for the Risk Engine.

For James, a simplified version of that case view may look like this:

IDENTITY VERIFICATION:
- Verification status: COMPLETED

SCREENING:
- Possible PEP status: IDENTIFIED
- Sanctions: NO_MATCH
- Adverse media: NO_MATCH
- Internal watchlist: NO_MATCH

BUSINESS STRUCTURE:
- Software company sale: SUPPORTED
- Planned $4 million business-sale funding: SUPPORTED

WEALTH AND FUNDS:
- Planned $1 million crypto funding: SUPPORTED
- Crypto exchange account ownership: SUPPORTED
- Crypto funding capacity: SUPPORTED
- Source of crypto funds: NOT_ESTABLISHED
- Crypto transaction screening: NO_CONCERN_IDENTIFIED

CLIENT PROFILE:
- Cross-border transactions expected: YES

This is the information the Risk Engine needs to apply the bank’s risk rules.

But before we look at how the Risk Engine does that, we need to answer a simple question.

What makes a client like James risky for the bank?

If James uses the bank for illegal activity, the bank can face serious penalties from regulators. 

So the bank cannot take on James as a client only because he is wealthy.

Before the bank takes James as a client, it needs to look at his full profile.

That includes who he is, where his money came from, and how he plans to use the account.

To do that, banks use internal risk rules to decide how deeply a client’s profile should be reviewed.

A high-net-worth client with a clear salary history, domestic transactions, and no political links may be onboarded quickly.

But James is different because he has a possible PEP status, expects cross-border transactions, and plans to bring in $1 million from crypto funds.

That means the bank’s internal rules would treat his case as one that needs deeper review.

In a real bank, the Risk Engine would apply those rules using the inputs from the Signal Aggregator.

It does not simply classify James as high risk and stop there.

It identifies which parts of James’s case need closer review and shows the compliance officer where to focus.

Let’s see how the Risk Engine does that.

Assume the bank has an internal rule like this: 

IF:
- Possible PEP status is identified
- Source of crypto funds is NOT_ESTABLISHED
- Cross-border transactions are expected

THEN:
- Classify the case as HIGH_RISK
- Send the case for ENHANCED_REVIEW
- Ask the compliance officer to review the possible PEP status
- Ask the compliance officer to review the source of crypto funds

The Risk Engine takes this rule and applies it to the case view prepared by the Signal Aggregator. 

For James, it separates the case into two parts. 

First, it identifies the parts that have been successfully reviewed: 

Identity verification: COMPLETED
Business-sale funding: SUPPORTED
Sanctions: NO_MATCH
Adverse media: NO_MATCH
Internal watchlist: NO_MATCH
Crypto transaction screening: NO_CONCERN_IDENTIFIED

Then it identifies the parts that need attention:

Possible PEP status: IDENTIFIED
Source of crypto funds: NOT_ESTABLISHED
Cross-border transactions expected: YES

The Risk Engine does not say every part of James’s case is a problem. It clearly separates what has been successfully reviewed from what still needs attention, and uses that combination to classify the case as high risk.

So the Risk Engine may return an output like this: 

RISK LEVEL:
HIGH

REVIEW ROUTE:
ENHANCED_REVIEW

SUCCESSFULLY REVIEWED:
- Identity verification is complete.
- No sanctions match was found.
- No adverse media concern was found.
- No internal watchlist match was found.
- The planned $4 million business-sale funding is supported.
- Crypto transaction screening did not identify a separate concern.

NEEDS REVIEW:
- Possible PEP status was identified.
- The source of James's crypto funds was not established.
- Cross-border transactions are expected.

REVIEWER FOCUS:
- Review the possible PEP status.
- Ask for or review records showing how James acquired the crypto funds.
- Confirm whether the expected cross-border transactions fit James's profile.
- Decide whether the case can proceed after enhanced review.

This output has been shortened for the article.

In a real bank, the Risk Engine output would usually be longer. It may show what was checked, what was cleared, and what still needs review. It may also explain why the case was sent for enhanced review and where the compliance officer should focus.

This detailed output is not the easiest format for a compliance officer to review quickly. 

That is where the LLM comes in.

The LLM (Large language model) takes that structured output and turns it into plain language that the compliance officer can read and act on quickly.

For example, the LLM may rewrite the Risk Engine output like this:

For James, identity verification is complete. No sanctions, adverse media, or internal watchlist match was found. The planned $4 million from business sale proceeds is also supported.

The review should focus on three areas.

First, possible PEP status was identified.

Second, the source of James's crypto funds was not established from the available evidence.

Third, James expects cross-border transactions, which adds to the need for enhanced review.

The compliance officer should review the possible PEP status, decide whether James needs to provide more records showing how he acquired the crypto funds, and consider the expected cross-border transactions as part of the enhanced review.

As you can see, the LLM has made the output easier for the compliance officer to understand quickly.

In the next post, we will look at the final step in the workflow: the case record.

This is where the bank records what happened in James’s case and why the final onboarding decision was made.

Tags: