Author: Manu

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

• The full agentic KYC workflow and architecture
  
• The CRM and Case Package layer
  
• The Workflow Controller
• The KYC Orchestrator
  
• The Identity Verification Agent
• The Screening Agent 
• The Wealth And Funds Review Agent
• The Signal Aggregator 
• The Risk Engine 
• The case store (this post)

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

By this point, the agents have reviewed James’s profile, and the Risk Engine has sent its output to the compliance officer. 

That output helps the compliance officer see the case clearly. It shows what the workflow has already reviewed and what still needs human review.

For James, the workflow has already verified his identity. The Screening Agent found no sanctions match, no adverse media concern, and no internal watchlist match. The Business Structure Review Agent also supported the planned $4 million transfer from his business sale.

But the case is not complete yet.

Three areas still need attention. James has a possible PEP status. The bank could not establish how he acquired his crypto funds. James also expects cross-border transactions.

That gives the compliance officer a clear starting point.

They do not need to review James’s whole case from scratch. The workflow has already verified James’s identity, checked the screening results, and reviewed the business sale. 

Now the compliance officer knows exactly where to focus: James’s possible PEP status, his crypto source of funds, and his expected cross-border transactions. 

Those details help the compliance officer decide whether the bank should take James on as a client. 

This is how the agentic workflow saves time for the compliance officer. It separates what the workflow has already reviewed from what the compliance officer still needs to review. 

Now the question is what the workflow stores after it runs. 

The workflow stores two types of data. 

The first is the workflow trace. 

The workflow trace shows how the agentic workflow ran.

It is mainly useful for debugging. It helps the bank see whether the workflow ran properly, whether the right agents were selected, and whether any step failed or paused.

For James, the trace would show that his case entered the workflow and that the Orchestrator created a plan. It would also show that the Orchestrator selected the Identity Verification Agent, the Screening Agent, the Business Structure Review Agent, and the Wealth and Funds Review Agent.

The trace would also show what an agent received and which tools it used.

For example, the Wealth and Funds Review Agent received the crypto exchange statement and the planned crypto funding amount. It then reviewed the exchange account and used a crypto transaction screening tool.

This kind of detail helps the team debug the workflow.

If the Wealth and Funds Review Agent keeps returning unclear findings, the team can use the trace to investigate what went wrong.

They can ask simple debugging questions.

• Did the agent receive the right input?
• Was the crypto exchange statement missing?
• Did the crypto screening tool fail?
• Did the agent return the finding in the wrong format?

The workflow trace helps the team answer these questions without guessing.

But the workflow trace only tells half the story. The bank also needs to explain why a particular decision was made on James’s case. 

That is where the case record comes in.

The case record stores the information the bank needs to explain James’s KYC review later to a regulator. 

It stores three things.

First, it stores what James declared.

James declared a business sale as his source of wealth. He planned to transfer $4 million from the business sale proceeds and $1 million from crypto funds. His profile also included possible PEP status and expected cross-border transactions.

Second, it stores what the workflow found.

James’s identity was verified. Screening found no sanctions match, no adverse media concern, and no internal watchlist match. The business sale review supported the planned $4 million transfer. The wealth and funds review showed that James had enough funds in his crypto exchange account, but the bank still had not established how he acquired those crypto funds.

Third, it stores the decisions made on the case.

The Risk Engine marked James’s case as high risk and routed it to enhanced review. It pointed the compliance officer to three areas: possible PEP status, the source of crypto funds, and expected cross-border transactions.

The compliance officer then asked for more information. James needed to provide records showing how he acquired the crypto funds. The business sale funding was supported, but the source of the crypto funds still needed review.

That is what the case record is built for.

If a regulator asks why James was approved or rejected, the bank can point to the case record and show exactly how the decision was made. 

Where does all this data get stored?

To make this easier to understand, let’s use the AWS version of this workflow as an example.

I covered the full AWS architecture in my AWS KYC workflow post. But here, we only need to focus on one thing: where the data gets stored after the Risk Engine gives its output. 

In a real bank, this data usually does not sit in one system. Documents, case status, workflow logs, agent outputs, and final decisions often live in different places.

In the AWS version of this workflow, the data is spread across four systems.

Amazon S3 stores the documents James uploaded during onboarding. His business sale agreement, bank statements, and crypto exchange statement all sit here, along with any facts extracted from those documents.

Amazon DynamoDB stores the live case state while the workflow runs. As each agent completes its review, DynamoDB holds the latest case status, agent findings, Risk Engine outcome, and AI Reviewer Summary.

AWS Step Functions records how the workflow moved from one step to the next. It shows when each agent ran, whether a step failed, and whether the workflow paused at any point.

CloudWatch logs capture the technical details from each step. If something goes wrong, the team can use these logs to find where the workflow broke down.

The final case record goes into the bank’s case management and audit systems. This is where the compliance officer’s decision lives. It captures the reason for the decision, the date it was made, and who made it.  

So the bank does not rely on one database to understand the whole case.

It looks across these systems to answer two different questions.

1. How did the agentic workflow run?
2. And why was this decision made for James’s case?

Here is what we covered.

The workflow stores two types of data: the workflow trace and the case record.

The workflow trace shows how the agentic workflow ran. The case record shows why the final decision was made on James’s case. Together, they give the bank what it needs to check whether the workflow ran properly and explain the decision to a regulator. Not just in a demo. But in production.

In my earlier posts, I explained an agentic KYC workflow using James’s onboarding case.

In this post, I map that workflow to AWS.

This is not the only way to build it.

It is one way to show how the main parts of the workflow could run on AWS:

• intake
• document storage
• event processing
• case state
• agent orchestration
• specialist agents
• tools
• risk rules
• human review
• downstream systems

The architecture uses AWS services such as:

• Amazon S3
• Amazon MSK
• AWS Lambda
• Amazon DynamoDB
• AWS Step Functions
• Amazon Bedrock AgentCore Runtime
• AgentCore Gateway
• Amazon Bedrock Knowledge Bases

The diagram shows how James’s case could move from Salesforce into an agentic KYC workflow, then into human review and downstream banking systems.

I am not writing the full AWS walkthrough yet. But if enough people are interested, I may write a separate post explaining how this architecture works step by step.

If you would like to see that post, email me at [email protected].

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

• The full agentic KYC workflow and architecture
  
• The CRM and Case Package layer
  
• The Workflow Controller
• The KYC Orchestrator
  
• The Identity Verification Agent
• The Screening Agent 
• The Wealth And Funds Review Agent
• The Signal Aggregator 
• The Risk Engine (this post)

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

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.

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

• The full agentic KYC workflow and architecture
  
• The CRM and Case Package layer
  
• The Workflow Controller
• The KYC Orchestrator
  
• The Identity Verification Agent
• The Screening Agent 
• The Wealth And Funds Review Agent
• The Signal Aggregator (this post)

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

The four specialist agents have now returned their findings for James’s case. 

• The Identity Verification Agent checked who James is.
• The Screening Agent checked for possible PEP status, sanctions, adverse media, and internal watchlist concerns.
• The Business Structure Review Agent checked his software company sale and the $4 million he plans to bring in from those sale proceeds.
• The Wealth and Funds Review Agent checked the $1 million he plans to bring in from crypto funds.

Each agent answered a different question about James’s case and returned its own finding. 

But the Risk Engine does not need every detail returned by all four agents.

Let’s use the Wealth and Funds Review Agent’s finding to see why.

James plans to bring $1 million into the new account from crypto funds held through his crypto exchange account.

The Wealth and Funds Review Agent checked those crypto funds and returned this finding:

STATUS: COMPLETED_WITH_SIGNAL

WHAT THE Available Evidence SHOW:
- James's crypto exchange account belongs to him.
- The account holds enough funds for the planned $1 million transfer.
- The available crypto transaction history was reviewed.

SIGNAL IDENTIFIED: 
- The source of James’s crypto funds was not established from the available evidence.

EVIDENCE STILL NEEDED:
- Other records showing how James acquired the crypto funds

SOURCES CHECKED:
- Crypto exchange account statement
- Crypto transaction history

NEXT STEP:
Send the finding and identified signal to the Signal Aggregator.

This detailed finding is useful. It shows what the agent checked and why it identified an issue. 

The Workflow Controller records this detailed finding and the sources checked in James’s case file. 

But the Risk Engine does not need this full explanation before it applies the bank’s risk rules. 

It only needs the key results:

• James plans to bring in $1 million from crypto funds.
• His crypto exchange account belongs to him.
• The account holds enough funds for the planned transfer.
• The source of the crypto funds was not established.
• The crypto transaction screening did not identify a separate concern.

Now imagine the Risk Engine doing this for the findings from all four specialist agents. It would have to extract the key result from each finding before it could apply any rules. 

And only then could the Risk Engine apply the bank’s rules.

That would give the Risk Engine two tasks: 

• prepare a clean case view from the specialist-agent findings; and 
• decide what should happen next in James’s case.

The Risk Engine should not have to do both. 

That is why an agentic KYC workflow needs a Signal Aggregator.

The Signal Aggregator receives the findings from the Workflow Controller. It takes the key results from each finding and brings them together into one clear case view for the Risk Engine.

How the Signal Aggregator packages a finding 

Let’s use the Wealth and Funds Review Agent’s finding again.

The table below shows how the Signal Aggregator extracts the key results from that finding and formats them for the Risk Engine.

Here, the Wealth and Funds Review Agent found that James did not provide enough evidence to show where his crypto funds came from.  

The Signal Aggregator packages that result as: crypto_source_of_funds_status = NOT_ESTABLISHED

This does not mean the Signal Aggregator has decided how risky James is.

It has only taken the useful information from the agent’s finding and placed it into a format the Risk Engine can use.

The Signal Aggregator does the same thing for the findings from the other specialist agents.

It brings the key results together and returns one clean output for the Risk Engine. 

What the Signal Aggregator returns

The final output may look like this:

{
  "case_view_status": "READY_FOR_RISK_ENGINE",

  "identity": {
    "verification_status": "COMPLETED",
    "verification_method": "DUAL_PROCESS"
  },

  "screening": {
    "possible_pep_status": "IDENTIFIED",
    "sanctions_status": "NO_MATCH",
    "adverse_media_status": "NO_MATCH",
    "internal_watchlist_status": "NO_MATCH"
  },

  "business_structure": {
    "software_company_sale_status": "SUPPORTED",
    "planned_business_sale_funding_amount": 4000000,
    "planned_business_sale_funding_source_status": "SUPPORTED"
  },

  "wealth_and_funds": {
    "planned_crypto_funding_amount": 1000000,
    "crypto_exchange_account_ownership_status": "SUPPORTED",
    "crypto_funding_capacity_status": "SUPPORTED",
    "crypto_source_of_funds_status": "NOT_ESTABLISHED",
    "crypto_transaction_screening_status": "NO_CONCERN_IDENTIFIED"
  },

  "client_profile": {
    "expected_cross_border_transactions": true
  }
}

This output gives the Risk Engine one clear view of James’s case. 

It shows that:

• His identity verification was completed.
• A possible PEP status was identified.
• No sanctions, adverse media, or internal watchlist match was found.
• The business sale and the source of the planned $4 million were supported.
• The crypto exchange account belongs to James and holds enough funds for the planned $1 million transfer.
• The source of those crypto funds was not established, and
•  James expects cross-border transactions.

The Risk Engine can now apply the bank’s rules to this case view and decide what should happen next in James’s case.

Let’s quickly recap

The specialist agents returned separate findings about James’s identity, screening, business sale, and crypto funds.

The Signal Aggregator takes the key results from those findings and formats them for the Risk Engine.

The Risk Engine takes that structured information and applies the bank’s rules.

In the next post, we will look at how the Risk Engine uses this output to decide what should happen next in James’s case.

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

• The full agentic KYC workflow and architecture
  
• The CRM and Case Package layer
  
• The Workflow Controller
• The KYC Orchestrator
  
• The Identity Verification Agent
• The Screening Agent 
• The Wealth And Funds Review Agent (this post).

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

James sold his software company last year for $18 million.

He now wants to open a new bank account with a Canadian bank and transfer $5 million into that account. 

Of that $5 million, $4 million comes from the business sale proceeds he currently holds in his existing bank account. The remaining $1 million comes from crypto funds held through a crypto exchange.

The bank cannot open the account based only on what James has declared. It needs to understand where the $5 million will come from.

The $5 million James wants to transfer raises two different questions. 

1. Can the bank confirm the business sale and the source of the $4 million James plans to transfer?
2. Can James show where the remaining $1 million in crypto funds came from?

Two separate agents need to answer these questions. 

The Business Structure Review Agent answers the first question. It checks whether James owned the software company and whether he plans to transfer the $4 million from those sale proceeds.

The Wealth and Funds Review Agent answers the second question. It checks the $1 million James plans to bring in from crypto funds.

This separation becomes important when the client’s business structure is more complex.

Imagine a client with several businesses.

One business may be owned through a holding company. Another may be connected to a trust. Funds may pass through several companies before they reach the client’s personal account.

Now imagine one agent trying to understand structures like these across thousands of clients.

It would need to examine the companies, the ownership links, and the funds connected to the business. At the same time, it would need to check the client’s personal wealth and funds.

That would give one agent two very different responsibilities.

So the workflow separates them.

The Business Structure Review Agent focuses on the companies, the ownership links, and the funds connected to the business.

The Wealth and Funds Review Agent focuses on the client’s personal wealth and funds.

This makes each review easier to understand, test, and explain.

In this article, I will explain James’s business sale briefly so that the $5 million he wants to transfer is easy to follow. But the Business Structure Review Agent handles that review.

I will break down the Business Structure Review Agent in more detail in a future post.

For now, we only need to see how the $4 million James plans to transfer came from his business sale.

James says he received $18 million from selling shares in his software company.

To check that declaration, the Business Structure Review Agent uses the business sale agreement James provided. The agreement may show:

• James’s name as the seller;
• the shares he agreed to sell;
• the name of his software company;
• the buyer’s name;
• the $18 million sale amount; and
• the closing date or closing terms.

But the agent does not rely only on the document James provided.

It may also check an official corporate registry. In Canada, this could be Corporations Canada if the company was federally incorporated, or a provincial registry if the company was incorporated provincially.

The registry helps the agent check whether the software company exists and whether James was connected to it.

But the registry does not show that James sold his shares for $18 million or that he received the sale proceeds.

To check that, the agent uses the sale documents and James’s existing bank account statement to see whether money from the sale came into his account.

In James’s case, the statement shows that he received the $18 million from the software company sale in his existing bank account. 

He plans to transfer $4 million from that account into his new bank account.

James has not sent the money yet. So the bank cannot confirm that the $4 million came from his existing account during onboarding.

For now, the bank can establish that James plans to fund the new account with $4 million from the account where he received the business sale proceeds.

Once James makes the transfer, the bank can confirm whether the $4 million came from that account.

Now let’s turn to the part handled by the Wealth and Funds Review Agent.

Can James show where the remaining $1 million will come from?

James has not transferred the remaining $1 million into the new bank account yet. So the Wealth and Funds Review Agent first checks whether he can show where that money will come from.

To do that, the agent uses the crypto exchange account statement James provided. 

The statement may show:

• his name as the account holder;
• the name of the crypto exchange;
• the value of the crypto funds held in the account; and
• the amount available for withdrawal or transfer.

This helps the agent check whether the account belongs to James and whether it has enough funds for the planned $1 million transfer.

But the statement only shows that James holds crypto funds in his exchange account. It does not show how he acquired those funds.

If the bank needs more evidence, the agent can request James’s crypto transaction history or other records showing how he acquired the funds.

The agent may also use an approved crypto transaction screening tool, such as Chainalysis or TRM Labs. The tool checks whether the available crypto transactions show links to sanctions, stolen funds, or scams.

These checks answer three different questions.

If the agent can answer these questions, it can support James’s declaration that he plans to fund $1 million of the new account from his crypto exchange account.

The agent now needs to return what it found to the Workflow Controller. 

What does the Wealth and Funds Review Agent return to the Workflow Controller? 

The Wealth and Funds Review Agent has now checked the crypto funds James plans to bring into the new account.

It has checked:

• whether the crypto exchange account belongs to James;
• whether the account holds enough funds for the planned $1 million transfer;
• whether James can show how he acquired the crypto funds; and
• whether the available crypto transactions identify anything the bank needs to review.

After these checks, the agent returns one of three findings to the Workflow Controller.

1. The documents and sources support what James declared

If the documents and other sources support James’s declaration, the agent returns:

Status: COMPLETED

Source of funds reviewed:
James plans to transfer $1 million from his crypto exchange account.

Finding:
The documents and other sources support James's declared crypto funds.

Sources checked:
- Crypto exchange account statement
- Crypto transaction history
- Approved crypto transaction screening tool

Next step: 
Confirm the actual incoming transfer once James funds the new account.

The Workflow Controller can then send this finding to the Signal Aggregator.

2. The agent completes its review and identifies missing evidence or a clear issue

Sometimes the agent can complete its review and identify a specific issue.

For example, James may show that his crypto exchange account belongs to him and holds enough funds for the $1 million he plans to transfer. But he may not provide enough records to show how he acquired those crypto funds.

He may also provide his crypto transaction history.

But those records may still not explain how he originally acquired the crypto funds.

In that case, the agent can clearly state what the available evidence shows and what remains unverified.

STATUS: COMPLETED_WITH_SIGNAL

WHAT THE Available Evidence SHOW:
- James's crypto exchange account belongs to him.
- The account holds enough funds for the planned $1 million transfer.
- The available crypto transaction history was reviewed.

SIGNAL IDENTIFIED: 
- The source of James’s crypto funds was not established from the available evidence.

EVIDENCE STILL NEEDED:
- Other records showing how James acquired the crypto funds

SOURCES CHECKED:
- Crypto exchange account statement
- Crypto transaction history

NEXT STEP:
Send the finding and identified signal to the Signal Aggregator.

The same approach applies if the crypto transaction screening clearly identifies a concern connected to James’s crypto funds. The agent can include that issue in its finding, and the Workflow Controller can then send the finding to the Signal Aggregator.

3. The agent needs human input before it can complete its finding

Sometimes the agent cannot complete its review without human input.

For example, the bank may use two approved crypto transaction screening tools to check James’s crypto funds and receive different results.

CRYPTO SCREENING TOOL A: No concern identified.

CRYPTO SCREENING TOOL B: Possible concern identified.

STATUS: HUMAN_REVIEW_REQUIRED

WHAT THE Available Evidence SHOW:
- James's crypto exchange account belongs to him.
- The account holds enough funds for the planned $1 million transfer.

ISSUE REQUIRING REVIEW:
Two crypto transaction screening tools returned different results for James's crypto funds.

SOURCES CHECKED:
- Crypto exchange account statement
- Crypto transaction screening tool A
- Crypto transaction screening tool B

REVIEWER FOCUS:
Review the conflicting crypto screening results and decide how the bank should treat the planned $1 million transfer.

The Workflow Controller pauses this part of the review and sends the specific issue to a compliance officer.

Once the compliance officer decides how the bank should treat the issue, the agent can complete its finding. The Workflow Controller can then send it to the Signal Aggregator.

This gives the Wealth and Funds Review Agent three possible outcomes:

These outcomes need to be built into the Wealth and Funds Review Agent. 

The agent should know when to complete its finding, send a clear issue to the Signal Aggregator, or request human input. 

The agent must also adapt to different sources of personal wealth and funds

The agent must do more than return a finding. It must also check the client’s personal wealth and funds based on where the client says the money came from. 

For example, a client may say their wealth came from selling real estate. The Wealth and Funds Review Agent would need to check the property sale evidence and the money the client received.

Another client may say their wealth came from an inheritance. The agent would need to check the inheritance documents and the money transferred to the client.

So the Wealth and Funds Review Agent cannot follow one fixed path. It runs the checks that apply to the client’s declared personal wealth and source of funds. 

Let’s quickly recap

The Wealth and Funds Review Agent checks what the client declared about their personal wealth and source of funds against documents, bank records, and reliable external sources.

It then returns a clear finding to the Workflow Controller. That finding may show that the available evidence supports what the client declared. It may identify missing evidence. Or it may explain an issue that needs human review before the workflow can continue.

That is how the Wealth and Funds Review Agent turns a client’s declaration into a finding that the rest of the workflow can use.

In the next post, we will look at the Signal Aggregator and how it brings the agents’ findings together.

The word “screening” instantly takes you to an airport.

You place your bag on the belt and walk through the scanner. The security team checks for things you should not carry on the flight.

Screening a banking client works in a similar way.

The bank is not checking the client physically. It is checking whether the client appears in sanctions lists, possible PEP records, adverse media sources, or internal watchlists. 

To understand how this works, let’s see how the Screening Agent helps the bank screen a client like James.

After the Orchestrator decides that the Screening Agent should run, the Workflow Controller sends the agent the details it needs.

{
  "agent_name": "screening_agent",

  "inputs": {
    "client_identity": {
      "full_name": "James Whitmore",
      "date_of_birth": "1964-04-12",
      "nationality": "Canadian",
      "country_of_residence": "Canada"
    },

    "client_profile": {
      "pep_declared": true,
      "expected_cross_border_transactions": true
    },

    "tax_profile": {
      "tax_residency": "Canada"
    }
  }
}

The Screening Agent uses these details to check multiple screening sources. For example, it may check sanctions lists, possible PEP status, adverse media, and the bank’s internal watchlist.

Adverse media means negative news or public information that may raise a concern about the client.

Banks may use screening providers such as World-Check, Dow Jones Risk & Compliance, or ComplyAdvantage. These providers help banks check many screening sources in one place, including sanctions records, possible PEP status, adverse media, and other watchlists.

Some banks may also use their own internal watchlist database.

Here is how that works for James.

The Screening Agent sends James’s details to a screening provider:

{
  "full_name": "James Whitmore",
  "date_of_birth": "1964-04-12",
  "nationality": "Canadian",
  "country_of_residence": "Canada"
}

The screening provider checks this information against its database.

That database may include PEP records, sanctions lists, adverse media sources, and internal watchlists.

The provider may return a result like this:

Possible PEP match found

Matched fields:
- name
- date of birth
- nationality

No sanctions match
No adverse media match
No internal watchlist match

This is only one provider’s result.

In a real bank, the Screening Agent may receive results from more than one screening provider or internal database.

For example:

Screening provider A:
- Possible PEP match
- Name, date of birth, and nationality matched
- Vendor score: 0.94
- No sanctions match
- No adverse media match

Screening provider B:
- Possible PEP match
- Name and date of birth matched
- Vendor score: 0.87
- No sanctions match
- No adverse media match

Internal bank watchlist:
- No match

The Screening Agent then consolidates the providers’ results. It compares the matched fields, checks whether the providers agree, and applies the bank’s screening rules.

Those rules tell the agent how to treat each result.

For example:

These conditions should be built into the Screening Agent so it does not guess. It should know when to mark a match as strong, when to mark it as weak, and when to send the issue for human review.

The final output from the Screening Agent may look like this:

{
  "screening_status": "POTENTIAL_MATCH",
  "hit_type": "POSSIBLE_PEP_STATUS",
  "match_strength": "STRONG",

  "providers_checked": [
    "screening_provider_a",
    "screening_provider_b",
    "internal_bank_watchlist"
  ],

  "sanctions_match": false,
  "adverse_media_match": false,
  "internal_watchlist_match": false,

  "requires_human_review": true,

  "summary": "Two screening providers returned a possible PEP match for James. No sanctions, adverse media, or internal watchlist match was found."
}

As you can see, the output clearly explains the issue. Two providers returned a possible PEP match for James, but there was no sanctions match, no adverse media match, and no internal watchlist match.

The Workflow Controller then takes this output and sends it to the Signal Aggregator.

Screening does not always return a clear result.

When that happens, the agent should return the issue for human review instead of deciding on its own.

Here are three common scenarios.

The first scenario is a partial match. James’s name may match a possible PEP record, but the date of birth may not match. In that case, the Screening Agent should not treat it as a confirmed match. It should return the issue to the Workflow Controller so a compliance officer can decide whether it is the same person or a false positive.

The second scenario is disagreement between providers. One screening provider may return a possible PEP match, while another provider may return no match. The Screening Agent should not blindly choose one provider over the other. It should flag the disagreement and ask for human review.

The third scenario is adverse media that needs interpretation. A screening provider may return a possible adverse media hit, but the article may be old, unclear, or about a different person with a similar name. The Screening Agent can flag the result, but a human reviewer may need to decide whether the article is relevant to James’s case.

These conditions must be built into the Screening Agent. The agent should know when the result is clear enough to send back to the Workflow Controller and when it needs human review.

In these situations, the Screening Agent returns a status such as:

HUMAN_REVIEW_REQUIRED

Or

NEEDS_MORE_INFORMATION

For example:

{
  "screening_status": "HUMAN_REVIEW_REQUIRED",

  "reason": "One provider returned a possible PEP match, but another provider returned no match.",

  "review_focus": [
    "Compare provider results",
    "Review matched fields",
    "Determine whether the hit is a true match or false positive"
  ]
}

The Workflow Controller then pauses the screening step and decides what should happen next. It may route the issue to a compliance officer, send it to a screening operations team, or request more information from the relationship manager.

Once the human reviewer resolves the issue, the workflow can continue working on the case.

That is how the Screening Agent handles unclear screening results.

Let’s quickly recap what we saw.

The Screening Agent checks James’s profile against relevant screening sources by sending his details to screening providers and internal systems. It consolidates the results, applies the bank’s screening rules, and returns a clear screening result to the Workflow Controller.

Sometimes that result is clear enough for the workflow to continue. But when the result is unclear, the agent does not guess and returns the issue for human review. That includes a partial match, disagreement between providers, or adverse media that needs interpretation.

That is how the Screening Agent screens James’s profile inside the agentic KYC workflow.

Just like airport screening, the goal is not to stop every person from moving forward. The goal is to find the cases that need closer attention before they pass through.

In the next post, we will look at the Wealth and Funds Review Agent and how it reviews James’s source of wealth, source of funds, and crypto funds.

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

Verifying a client’s identity sounds simple.

The client gives the bank a government ID. The bank checks the name, address, and date of birth against the details the client provided.

And that may be enough in some cases.

But identity verification is not always that simple. 

The name may be slightly different, or the address may not line up. In more complex cases, the bank may need to check the client’s details against another reliable source. 

But before we get into that, let’s start with the basics.

What is identity verification?

Identity verification is the step where the bank confirms that the client is who they say they are.

This is usually one of the first things that happens when someone opens a bank account.

The bank may ask for a government ID, such as a passport or driver’s licence, but a government ID is only one way to verify a client’s identity.

In Canada, FINTRAC describes five methods to verify the identity of a person:

• government-issued photo identification method
• credit file method
• dual-process method
• affiliate or member method
• reliance method

The bank does not use all five verification methods for every client. It chooses the method based on the client’s risk profile and how complex the case is. Let’s look at two examples.

For a client with a simple profile, such as a high-income employee, one government-issued photo ID may be enough. The bank checks the name, address, and date of birth against the ID and moves forward.

For a client like James, the bank may need to verify his identity using more than one source. That is because he has declared possible PEP status, business sale wealth, crypto funds, and expected cross-border transactions. So the bank may use dual-process verification, which checks the client’s identity using two or more reliable sources. 

Now, let’s see how the Identity Verification Agent works for James.

The Orchestrator has already decided that James should go through dual-process verification. The Workflow Controller passes that instruction to the Identity Verification Agent. It also sends James’s identity details, document references, proof of address, and consent records. 

{
  "agent_name": "identity_verification_agent",

  "method": "DUAL_PROCESS",

  "inputs": {

    "client_identity": {
      "full_name": "James Whitmore",
      "date_of_birth": "1964-04-12",
      "address": "Toronto, Canada"
    },

    "documents": {
      "government_id": "cloud://kyc-documents/KYC-123/government_id.pdf",
      "proof_of_address": "cloud://kyc-documents/KYC-123/proof_of_address.pdf"
    },

    "consent_records": {
      "credit_bureau_consent": true
    }
  }
}

Because the method is dual-process, the agent checks James’s declared identity details against two reliable sources. One source may be a credit bureau check through Equifax or TransUnion. Another may be an identity verification tool, such as Trulioo, Onfido, or Jumio.

The agent then compares those results with the identity details James provided. If there is a mismatch, it returns the issue to the Workflow Controller. 

If everything matches, the agent returns a clear output showing the method it used, the sources it checked, and the tools it called. For example, the output may look like this: 

{
  "identity_status": "PASS",

  "method_used": "DUAL_PROCESS",

  "sources_checked": [
    "credit_bureau_check",
    "identity_verification_tool"
  ],

  "tools_used": [
    "Equifax or TransUnion",
    "Trulioo"
  ],

  "match_result": "MATCH",

  "summary": "James's government ID was verified, and his name, date of birth, and address matched across two reliable sources."
}

This does not mean the agent verified James on its own. It followed the selected method, checked the approved sources, and returned a finding to the Workflow Controller.

The Workflow Controller records this output and moves the workflow to the next step.

Sometimes, the evidence the agent receives is not enough to complete the identity step.

For example, James may provide one address during onboarding, but the credit bureau check may return a different address. Or the name or date of birth on the government ID may not match the identity details James provided.

When that happens, the agent should return a status such as:

HUMAN_REVIEW_REQUIRED
or

NEEDS_MORE_INFORMATION
The Workflow Controller then pauses the identity step and decides what should happen next.

It may request updated information from the relationship manager or route the issue to a compliance officer.

These conditions must be coded into the Identity Verification Agent. For example, the agent may return an output like this:

{
  "agent_name": "identity_verification_agent",

  "identity_status": "HUMAN_REVIEW_REQUIRED",

  "reason": "Address mismatch between the identity details James provided and the credit bureau result.",

  "review_focus": [
    "Confirm current residential address",
    "Review proof of address"
  ]
}

With these conditions in place, the agent knows when it can complete the identity step and when it needs to return an issue to the Workflow Controller.

That is the role of the Identity Verification Agent. 

It follows the method selected by the Orchestrator, checks the client’s identity details against the right sources, and returns a clear identity finding.

For a client with a simple profile, the agent checks a government-issued photo ID. For a client like James, it checks whether his details line up across two reliable sources using the dual-process method.

If the details match across the sources, the agent returns a completed identity finding. If something does not line up, it returns the issue to the workflow for human review.

In the next post, we will look at the Screening Agent and how it checks James’s profile against sanctions lists, possible PEP status, and adverse media sources.

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

• The full agentic KYC workflow and architecture

• The CRM and Case Package layer

• The Workflow Controller

• The KYC Orchestrator (this post)

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

Imagine a conductor standing in front of a full orchestra.

Every musician is ready, but the music does not start until the conductor gives the signal.

The conductor decides who starts, who joins next, and how the entire piece comes together.

That is what the Orchestrator does in a KYC workflow.

The Workflow Controller runs the agents. But the Orchestrator decides the agent plan: which agents should run, how they should run, and what information each agent should receive.

To do that, the Orchestrator first receives a structured case package from the Workflow Controller.

For James, that package may look like this:

{
  "case_id": "KYC-123",

  "declared_profile": {
    "full_name": "James Whitmore",
    "source_of_wealth": "Sale of private business",
    "source_of_funds": "Crypto exchange transfer",
    "pep_declared": true
  },

  "document_refs": [
    {
      "document_id": "doc_003",
      "document_type": "bank_statement",
      "document_url": "cloud://kyc-documents/KYC-123/doc_003.pdf",
      "extracted_facts_url": "cloud://kyc-extracted-facts/KYC-123/doc_003_facts.json"
    }
  ]
}

The case package gives the workflow one structured view of the client’s declared details and supporting document references.

Once the Orchestrator has that view, it can build the agent plan.

The Orchestrator’s plan answers three simple questions:

• Which agents should run?
• How should each agent run?
• What information should each agent receive?

Those three answers decide how the rest of the workflow runs.

To see how this works in practice, let’s compare a simple client with James.

Imagine a client with a high salary, no business ownership, no crypto funds, and no cross-border transactions.

For this client, the Orchestrator creates a simple plan:

{
  "agents_to_run": [
    "identity_verification_agent",
    "screening_agent",
    "wealth_and_funds_review_agent"
  ],

  "agents_not_required": [
    "business_structure_review_agent"
  ],

  "agent_methods": {
    "identity_verification_agent": "government_issued_photo_id_method",
    "wealth_and_funds_review_agent": "standard_salary_income_review"
  },

  "agent_inputs": {
    "identity_verification_agent": [
      "client identity details",
      "government ID",
      "proof of address"
    ],

    "screening_agent": [
      "client identity details",
      "PEP declaration",
      "tax residency"
    ],

    "wealth_and_funds_review_agent": [
      "declared salary income",
      "recent bank statements",
      "employment or income details"
    ]
  }
}

The Business Structure Review Agent does not run because this client has no business context.

That is the point of the plan. The workflow does not run an agent just because the agent exists.

The agent_methods section tells each agent how to run.

For a client with a simple profile, the Orchestrator tells the Identity Verification Agent to use government-issued photo ID verification.

In Canada, FINTRAC allows different ways to verify a client’s identity. These include photo ID verification, credit file verification, and the dual-process method.

For a simple client, the Orchestrator chooses the government-issued photo ID method because the client’s identity can be verified with standard documents.

The agent_inputs section tells each agent what information and documents it needs to run.

Now compare that with James. 

James has declared possible PEP status, sold a private business, has crypto funds, and expects cross-border transactions.

For James, the Orchestrator creates a more detailed plan:

{
  "agents_to_run": [
    "identity_verification_agent",
    "screening_agent",
    "wealth_and_funds_review_agent",
    "business_structure_review_agent"
  ],

  "agent_methods": {
    "identity_verification_agent": "dual_process_method",
    "wealth_and_funds_review_agent": "enhanced_wealth_and_funds_review",
    "business_structure_review_agent": "business_sale_context_review"
  },

  "agent_inputs": {

    "identity_verification_agent": [
      "client identity details",
      "government ID",
      "proof of address",
      "consent records"
    ],

    "screening_agent": [
      "client identity details",
      "PEP declaration",
      "tax residency",
      "country exposure"
    ],

    "wealth_and_funds_review_agent": [
      "source of wealth declaration",
      "source of funds declaration",
      "bank statement",
      "business sale agreement",
      "crypto-related information"
    ],

    "business_structure_review_agent": [
      "business sale context",
      "business ownership information",
      "sale-related records"
    ]
  }
}

The Orchestrator includes the Business Structure Review Agent because James’s wealth came from a business sale.

It tells the Identity Verification Agent to use the dual-process method because James’s profile is more complex and the bank needs stronger identity evidence.

It asks the Wealth and Funds Review Agent to run an enhanced review because James’s case includes business sale proceeds and crypto funds. 

Why does the Orchestrator create two different plans for two different clients?

Because not every client needs the same agents, methods, or evidence.

For a client with a simple profile, the Orchestrator keeps the plan straightforward. It runs only the agents that are relevant, chooses standard methods, and avoids steps that do not apply to the case. That client can be onboarded faster because the system is not running unnecessary agents.

For a client like James, the Orchestrator builds a more detailed plan. It runs more agents, sends them more information, and asks them to use stronger methods because the case is more complex.

That is the value of the Orchestrator. It helps the workflow treat simple cases simply and complex cases carefully.

Why do we need both a Workflow Controller and an Orchestrator?

Why not let the Workflow Controller decide everything?

Because then the whole workflow becomes harder to manage. The Workflow Controller would have to decide which agents should run, run those agents, handle pauses, call the downstream steps, and record what happened.

And when that happens, the workflow becomes difficult to understand, test, and explain.

In banking, that matters. 

If a regulator asks why a case followed a certain path, the bank needs a clear answer. It needs to show the rules it applied, the steps it ran, and why the case moved in that direction.

That becomes much harder when one part of the workflow does everything.

The cleaner design is to separate the two tasks.

The Orchestrator decides the plan. 

The Workflow Controller runs it.

And because they are separate, the bank can improve one without changing the other.

For example, if the bank decides that every high-net-worth client with crypto funds now needs enhanced wealth review, the team can update the Orchestrator. The Orchestrator builds a different plan for those clients, but the Workflow Controller still runs the plan the same way.

If the bank changes how cases pause and resume, the team updates the Workflow Controller. A missing source-of-funds document may create a task for the relationship manager, while a possible PEP match may go to a compliance officer. The Orchestrator stays the same.

That is the benefit of keeping them separate. 

The workflow becomes easier to update, test, and explain to a regulator later.

That is how the agentic KYC workflow gets direction. 

The Orchestrator decides which agents should run, how they should run, and what information they should receive.

Like the conductor, it does not play every instrument. It keeps the workflow moving in the right order.

In the next post, we look at the first specialist agent in the workflow: the Identity Verification Agent.

In the first post, we looked at the full agentic KYC workflow for high-net-worth onboarding.

In the second post, we zoomed into the CRM and Case Package piece. That is where the relationship manager captures the client information, uploads the documents, and creates the structured case package that starts the workflow.

Now we are looking at the next piece: the Workflow Controller.

The Workflow Controller is the engine that drives the entire workflow. It starts with the case package and coordinates everything that follows. The Orchestrator, the specialist agents, the Signal Aggregator, and the Risk Engine all run under its watch until the final output reaches the compliance officer.

But coordinating the agents is only part of what it does. 

The Workflow Controller also decides whether the case should continue, pause, request more information, or go to a compliance officer for review.

Let’s see how it does that.

It works with the Orchestrator to decide which agents to run. 

The first thing the Workflow Controller does is send the case package to the Orchestrator.

The Orchestrator looks at the case and creates a plan. In James’s case, the plan calls for running four specialist agents: the Identity Verification Agent, the Screening Agent, the Wealth and Funds Review Agent, and the Business Structure Review Agent.

The plan also specifies which information each agent should use. For example, the Identity Verification Agent receives James’s identity details, government ID, and proof of address. The Wealth and Funds Review Agent receives his wealth profile, source of funds, bank statement, and business sale agreement.

The Workflow Controller then takes that plan and runs each agent with the right inputs.

In the previous post, we looked at the full agentic KYC workflow for high-net-worth onboarding.

In this post, we are zooming into the first piece of the workflow: CRM / Case Package. 

This is where the workflow begins. And it matters more than it looks.

If the case package is messy, everything downstream breaks down. The Orchestrator gets poor inputs. The specialist agents receive incomplete information. The Signal Aggregator has less to work with. The Risk Engine may make a decision based on an incomplete picture.

So before we talk about agents, orchestration, or AI summaries, we need to answer a simple question: 

How does a high-net-worth client’s information get into the workflow in a clean format?

To answer that, we start with the relationship manager.

The relationship manager captures three types of client information from James in a CRM.

First, declared information. This is what the client tells the bank: their name, address, occupation, source of wealth, source of funds, and more.

Second, documentary evidence. These are documents that support the declared information: government ID, bank statements, business sale agreement, and more.

Third, consent records. This allows the bank to run third-party checks. For example, credit bureau consent allows the bank to verify the client’s credit history.

The bank collects all this information because regulations demand it.

In Canada, the Proceeds of Crime (Money Laundering) and Terrorist Financing Act (PCMLTFA) and FINTRAC guidance set the rules. Banks must verify client identity, understand the purpose of the relationship, and determine the source of funds.

How the client information gets to the Workflow Controller

The CRM does not send raw notes and uploaded files directly to the Workflow Controller.

First, the information has to be captured, stored, classified, extracted, and packaged.

Let’s use Google Cloud as an example:

Let’s walk through each step.

First, the relationship manager captures the client information in the CRM.

Second, the uploaded documents are sent to Google Cloud Storage.

Third, Google Document AI classifies each document.

This means it identifies what type of file was uploaded.

For example:

• This document is a government ID.
• This document is a bank statement.
• This document is a business sale agreement.

Fourth, Google Document AI extracts key information from each document.

For example, from a government ID, it may extract: name, date of birth, issuing country, and expiry date.

Fifth, the extracted facts are saved as JSON files in Google Cloud Storage.

For example, the original bank statement may be stored here: cloud://kyc-documents/KYC-123/doc_003.pdf

And the extracted facts may be stored here: cloud://kyc-extracted-facts/KYC-123/doc_003_facts.json

So the raw document and the extracted facts are both stored in the cloud, but as separate files.

Sixth, Google Cloud Workflows packages the information.

This is the step that brings everything together: client information from the CRM, document links from Google Cloud Storage, extracted facts from the JSON files, consent records, and case information.

Google Cloud Workflows acts as the coordinator in this example. It pulls the pieces together and prepares the structured case package.

Finally, the Workflow Controller receives the structured case package.

For example:

{
  "case_id": "KYC-123",
  "declared_profile": {
    "full_name": "James Whitmore",
    "source_of_wealth": "Sale of private business",
    "source_of_funds": "Crypto exchange transfer",
    "pep_declared": true
  },
  "document_refs": [
    {
      "document_id": "doc_003",
      "document_type": "bank_statement",
      "document_url": "cloud://kyc-documents/KYC-123/doc_003.pdf",
      "extracted_facts_url": "cloud://kyc-extracted-facts/KYC-123/doc_003_facts.json"
    }
  ]
}

As you can see, the Workflow Controller does not receive raw PDFs or scattered notes. It receives a clean, structured case package it can immediately start working with.

So let’s quickly recap what we covered.

The relationship manager captures three types of client information: what the client declares, the documents that support that declaration, and the consent records that allow the bank to run third-party checks. All of that information goes into the CRM.

From there, the documents are stored, classified, and extracted. The extracted facts and document references are packaged together. And the Workflow Controller receives one clean starting point.

That is the CRM and Case Package piece. It is not the most visible part of the workflow, but it is the part that every downstream agent depends on.

In the next post, I will show how the Workflow Controller uses that case package to start the workflow, call the Orchestrator, run the required agents, and return the final output.