A PEP is the politically exposed individual who currently holds or has held a prominent public role. A relative or close associate, often called an RCA, is connected through family or business relationships and may not hold public office themselves. RCAs are still flagged because proximity to power can create similar corruption, fraud, and money laundering risk.
Why This Matters for Security Teams
PEP screening is not only about identifying the public official. It is about understanding who else may be exposed through family, business, or informal influence networks that can be used to obscure beneficial ownership, move funds, or pressure decision-makers. For financial crime teams, the practical question is how to convert a legal distinction into a usable risk signal without overloading analysts or creating inconsistent outcomes across onboarding, periodic review, and event-driven alerts.
The main operational mistake is treating RCAs as a separate, lower-priority population that can be handled with weaker scrutiny. That approach misses the reason they are screened at all: they can present similar corruption, bribery, sanctions-evasion, or fraud risk even when they do not hold office themselves. A well-run program therefore maps both PEPs and RCAs into the same governance model, while allowing risk scoring to reflect the relationship type, geography, source of wealth, and transaction behaviour.
For control design, the relevant baseline is strong identity and access governance, documented escalation paths, and repeatable review criteria, which aligns well with the structure of NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many compliance failures appear only after a customer is already onboarded and the relationship network has been reconstructed too late for clean remediation.
How It Works in Practice
In practice, PEP and RCA handling begins with classification, not just matching. A PEP is assigned because of the person’s current or former public function. An RCA is assigned because of proximity to that person through family ties, close personal relationships, or a materially relevant business connection. The distinction matters because the source of risk is different, even if the control response is similar.
Effective programs usually separate three steps:
- Identification, where screening tools and due diligence teams determine whether the subject is the office-holder or a connected person.
- Risk assessment, where the organisation weighs jurisdiction, role seniority, relationship strength, ownership links, and transaction patterns.
- Treatment, where enhanced due diligence, senior approval, and ongoing monitoring are applied in proportion to risk.
This is where governance often becomes uneven. Some firms over-index on the label and treat every RCA as if the risk were identical. Others under-react and require proof of direct influence before applying controls. Current guidance suggests neither extreme is reliable. The more defensible approach is to record the relationship basis explicitly and make the control decision traceable, so analysts can explain why a spouse, sibling, business partner, or nominee may still merit enhanced review.
For broader threat context, the ENISA Threat Landscape is useful when teams need to understand how fraud, social engineering, and identity abuse intersect with financial crime risk. These controls tend to break down when customer data is fragmented across onboarding, sanctions, and case-management systems because relationship evidence cannot be assembled quickly enough to support a consistent decision.
Common Variations and Edge Cases
Tighter PEP and RCA screening often increases false positives, remediation effort, and customer friction, requiring organisations to balance stronger risk coverage against onboarding speed and investigative capacity.
There is no universal standard for every borderline case. Some jurisdictions and regulators treat domestic PEPs, foreign PEPs, and international organisation officials differently. Others expect RCAs to include household members, beneficial owners, and business associate, but leave the exact scope to local policy. That means the same relationship may be high risk in one regime and moderate risk in another.
Edge cases also arise when the connection is informal rather than legal. A long-term partner, nominee director, or trusted business intermediary may not fit a narrow family definition, yet still create the same practical exposure. Best practice is evolving toward risk-based inclusion of these relationships when the factual pattern supports it, but organisations should document the rationale carefully because consensus is not complete.
The hardest cases are those involving indirect ownership, layered corporate structures, or rapidly changing political office. In those environments, a one-time classification is rarely enough. The safer approach is continuous monitoring, periodic re-screening, and escalation when relationship or control evidence changes. That is especially important where a supposedly low-risk RCA is later revealed to be acting as a proxy for the PEP’s assets or influence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-63 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | PEP/RCA decisions require documented risk appetite and consistent treatment. |
| NIST SP 800-63 | Identity proofing supports reliable subject matching in PEP and RCA screening. | |
| PCI DSS v4.0 | 10.2 | High-risk relationship monitoring benefits from auditable event and case logging. |
Define risk thresholds for PEP and RCA cases and apply them consistently in screening and review.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
