Start with risk-based onboarding and use KYCC only where the customer’s business model creates downstream exposure, such as payment processing, BaaS, correspondent banking, or crypto services. Combine KYC, KYB, AML screening, and ongoing transaction monitoring, then escalate high-risk relationships for deeper review. The goal is to understand who your customer serves and where indirect money laundering risk can hide.
When KYCC Should Be Narrowly Targeted, Not Turned into a Parallel KYC Programme
KYCC works best as an overlay on existing customer due diligence, not as a separate universal process. In intermediary models, the practical question is whether the customer’s own activity can transmit money laundering risk downstream. That means focusing on business models with meaningful flow-through exposure, while avoiding blanket reviews of low-risk intermediaries that only add friction.
The starting point is segmentation. A payments processor, BaaS provider, correspondent bank, or crypto service can create materially different downstream exposure than a standard software reseller or professional services firm. The more the customer sits between funds, accounts, and third parties, the more likely KYCC will add value beyond ordinary third-party trust assurance and basic onboarding checks.
That does not mean every intermediary needs deep transparency over every end user. It means the programme should identify which relationship types materially alter the risk picture, then reserve KYCC for those cases. A risk-based scope keeps controls proportional and helps compliance teams avoid collecting information that they cannot operationalise in monitoring, escalation, or case management.
What a Proportionate KYCC Control Set Actually Covers
A workable KYCC design usually extends existing KYC and KYB logic rather than replacing it. The team should understand the intermediary’s customer base, payment rails, product mix, geographies, and the kinds of counterparties or merchants it serves. That review is most useful when it explains where indirect exposure could enter the institution through otherwise legitimate client activity.
Operationally, this means combining source onboarding data with sanctions and AML screening, adverse media review where relevant, and ongoing transaction monitoring that reflects the intermediary’s throughput and customer profile. If the intermediary aggregates activity across many end users, the monitoring question is not just who the customer is, but whether patterns in the downstream flow create indicators that the intermediary relationship is being used to obscure origin, destination, or control of funds.
Proportionate KYCC also depends on escalation thresholds. Where a relationship has complex nested customers, cross-border flows, virtual assets, or high-risk merchant categories, deeper review is justified. Where the intermediary’s model is low-risk and operationally transparent, the programme should stay lighter and rely on standard due diligence plus alert-driven escalation rather than constant bespoke review.
How to Keep KYCC from Expanding Into Unmanageable Scope
Compliance teams overextend KYCC when they treat “intermediary” as a category that automatically demands full visibility into every downstream customer. The better rule is to define the specific risk trigger that justifies the extra work, then set limits on depth, cadence, and evidence requirements. That preserves investigative capacity for the relationships most likely to hide indirect laundering risk.
The other common failure is trying to make KYCC do the job of the entire AML stack. It should inform onboarding, monitoring, and escalation, but not replace transaction surveillance, investigations, or standard customer risk scoring. When KYCC findings are not connected to an operating control, the programme becomes expensive documentation rather than a risk reduction tool.
At scale, the key judgement is whether KYCC evidence can be maintained and reviewed consistently across business lines. If the answer is no, the scope is probably too broad. Teams should prefer a smaller set of well-understood high-risk intermediary types, with clear triggers for refreshing the review when products, counterparties, or transaction patterns change.
Risk and Threat Considerations
Intermediary businesses can hide indirect exposure because the institution rarely sees the full customer chain. That creates a risk that illicit funds, sanctioned counterparties, or layered transactions move through a seemingly ordinary relationship while the true exposure sits one or two tiers downstream.
Failure mechanism: KYCC fails when the team broadens review to every intermediary relationship, or narrows it so much that high-risk flow-through models are treated like ordinary customers. In both cases, the programme loses discrimination, and suspicious patterns can blend into normal volume.
Impact: The result is either control fatigue and wasted analyst effort, or missed typologies that should have triggered deeper due diligence, enhanced monitoring, or account restriction. In regulated sectors, that can translate into weak AML outcomes and poor defensibility when a case is reviewed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | KYCC programs rely on controlled evidence, account data, and monitoring records. |
| Recommendation — Manage customer and intermediary credentials and evidence with defined lifecycle controls. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | KYCC scope should be set by risk appetite and downstream exposure. |
| ID.RA-01 — Asset Vulnerabilities Are Identified and Documented | KYCC needs identification of intermediary business-model exposure points. | |
| Recommendation — Define which intermediary relationships warrant look-through review. Document which intermediary models can transmit laundering risk downstream. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | KYCC relies on limiting access to sensitive due-diligence and monitoring data. |
| Recommendation — Restrict KYCC evidence and case access to approved compliance roles. | ||
| SOC 2 (AICPA) | CC6.1 — Logical and Physical Access Controls | KYCC workflows require controlled access to customer and monitoring information. |
| Recommendation — Limit KYCC case data access to authorised reviewers with business need. | ||
Practitioner Guidance
What to prioritise: Classify intermediary customers by downstream exposure first, then decide whether KYCC is needed for the relationship at all. If the model does not materially change how money, customers, or counterparties flow through the business, ordinary KYC/KYB and monitoring are usually enough.
What to verify: Make sure each KYCC trigger can be tied to a concrete business model feature, such as payment aggregation, nested accounts, correspondent activity, or crypto rails. If the trigger cannot be operationalised into onboarding questions, monitoring rules, or escalation criteria, it is probably too vague to sustain.
Common mistake: Treating KYCC as a universal “extra diligence” layer. That usually produces a larger programme without better detection, because analysts spend time collecting low-value information instead of reviewing relationships that actually carry indirect laundering risk.
Practitioner takeaway: The most effective KYCC programmes are selective, not exhaustive, they reserve deeper look-through review for intermediary models that can genuinely transmit financial crime risk downstream.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities for compliance?
- How should security teams govern non-human identities for SOC 2 compliance?
- How should organisations implement continuous PEP screening without overwhelming compliance teams?
- How should security teams implement PHI protection in AWS environments without relying on compliance labels alone?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
