How the Signal Aggregator Turns Separate Agent Findings Into One Clear Case View

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.