Skip to main content
a promotional graphic telling you that PCI Compliance is no longer an annual exercise and that continuous monitory must be built in
Third-Party Due Diligence Myths Costing You SleepSanctions Lists & Screening
5 min readFor FinTech Compliance Teams

Third-Party Due Diligence Myths Costing You Sleep

You've built your third-party risk program around assumptions that made sense five years ago. But geopolitical shifts, new criminal offense regimes like the UK's Failure to Prevent Fraud, and the expansion of sanctions to cryptocurrency exchanges have turned comfortable certainties into compliance blind spots.

These myths persist because they're rooted in how we used to manage third-party risk, when regulatory expectations were clearer, sanctions lists were simpler, and cryptocurrency wasn't a mainstream payment rail. That world is gone. Here's what's actually true now.

Myth 1: "We screen third parties at onboarding. That's sufficient."

Reality: Static screening creates a widening gap between your risk assessment and current exposure.

When conflicts in Iran and Ukraine shift criminal activity patterns, your third party's risk profile changes even if nothing about their business structure does. Gangs identify new routes to channel illicit money, and your vendor relationships become potential conduits without any visible red flag at your end.

Your Customer Risk Profile for third parties needs continuous inputs, not annual snapshots. This means:

  • Monitoring for beneficial ownership changes in real-time registries
  • Re-screening against sanctions lists weekly, not quarterly
  • Tracking adverse media that signals emerging corruption or fraud exposure
  • Watching for sudden changes in transaction patterns or geographic reach

The UK's Failure to Prevent Fraud offense makes this concrete: if your payment processor or correspondent bank relationship becomes a fraud conduit, your initial due diligence won't shield you from criminal liability. The regulation explicitly requires you to understand who your third parties are and how they expose you to risk on an ongoing basis.

Myth 2: "Cryptocurrency third parties are just another vendor category"

Reality: Cryptocurrency exchanges require fundamentally different due diligence frameworks because they operate across jurisdictions with asymmetric regulatory maturity.

When you work with a traditional payment processor, you're evaluating their AML/CFT framework within a known regulatory perimeter. Cryptocurrency exchanges don't fit that model. A single exchange might:

  • Hold licenses in three jurisdictions with different Customer Due Diligence thresholds
  • Process transactions through wallets registered in unregulated territories
  • Serve customers in Grey List jurisdictions while headquartered in a compliant one

Your due diligence questionnaire needs to map this complexity explicitly. Ask:

  • Which jurisdictions regulate each legal entity in their corporate structure?
  • Where are customer wallets domiciled, and what KYC applies to wallet creation?
  • How do they comply with Travel Rule requirements for cross-border transfers?
  • What sanctions screening controls apply to wallet addresses, not just account holders?

Don't treat "we're compliant with local regulations" as sufficient. Identify which regulations, in which jurisdictions, and how they verify compliance across fragmented operations.

Myth 3: "Risk-based due diligence means doing less work on low-risk vendors"

Reality: Risk-based means tailoring your questions and monitoring intensity to specific threat scenarios, not reducing effort.

You're not trying to do minimal due diligence on low-risk relationships. You're trying to ask the right questions that surface hidden exposure before it becomes a regulatory event.

A low-risk software vendor becomes high-risk the moment they subcontract payment processing to a third party in a sanctions-sensitive jurisdiction. A marketing agency becomes high-risk when they start handling customer data that could be used for identity fraud.

Build your risk framework around exposure pathways:

  • Access to customer data: What Personally Identifiable Information do they touch, and where is it stored?
  • Payment flow involvement: Do they initiate, process, or settle transactions on your behalf?
  • Geographic nexus: Where are their beneficial owners, employees, and subcontractors actually located?
  • Regulatory perimeter: Which of your compliance obligations extend to their activities?

Then map monitoring frequency and depth to those pathways, not to a generic vendor risk score.

Myth 4: "We can rely on third-party attestations and certifications"

Reality: Attestations tell you what controls exist, not whether they work or apply to your specific risk exposure.

A SOC 2 Type II report confirms that a vendor's security controls operated effectively during the audit period. It doesn't tell you whether their Beneficial Owner Identification process meets your jurisdiction's requirements, whether they screen against the same sanctions lists you do, or how they handle subcontractor risk.

ISO 37001 certification for anti-bribery management systems is valuable context. It's not a substitute for understanding how their payments to government officials in high-risk jurisdictions actually get approved and documented.

Use attestations as a starting point, then validate the specific controls that matter for your risk profile:

  • Request evidence of actual screening hits and dispositioning decisions
  • Review their sanctions policy to confirm list coverage matches your obligations
  • Test their incident response: ask how they'd notify you of a beneficial ownership change or adverse media event
  • Verify that their subcontractors meet the same standards, with contractual flow-down requirements

Myth 5: "Integrated due diligence is a technology problem"

Reality: Integration is a governance problem that technology supports.

You don't need a unified platform. You need a unified decision framework that connects what your sanctions team learns, what your fraud team sees, and what your vendor management function tracks.

When your fraud team identifies a pattern of synthetic identity creation linked to a payment aggregator, does that intelligence flow to the team managing that aggregator relationship? When your sanctions analysts see new designations related to proliferation financing networks, do your cryptocurrency exchange reviews get triggered for re-assessment?

Build integration through:

  • Shared escalation paths: Route third-party risk events to your MLRO with the same priority as internal suspicious activity
  • Cross-functional risk committees: Include vendor management, sanctions, fraud, and legal in quarterly third-party risk reviews
  • Unified risk taxonomies: Use the same risk categories and rating scales across Customer Due Diligence and third-party due diligence
  • Common data definitions: Ensure "beneficial owner", "high-risk jurisdiction", and "PEP exposure" mean the same thing in every assessment

Technology enables this by centralizing data and automating alerts. But the governance structure determines whether anyone acts on what the technology surfaces.

What to Do Instead

Start with your highest-exposure relationships and work backward to the assessment gaps.

Identify third parties who: process payments, hold customer funds, access Personally Identifiable Information, operate in jurisdictions affected by recent sanctions expansions, or touch cryptocurrency in any capacity. For each one, answer:

  1. When did we last verify beneficial ownership against current registry data?
  2. What would trigger an immediate re-assessment of this relationship?
  3. If this vendor appeared in adverse media tomorrow, who gets notified and what's the escalation timeline?
  4. Which of our regulatory obligations flow through to this vendor's operations?

Then build monitoring that answers those questions continuously, not annually. Your third-party risk program should surface problems before your regulator does. FATF Recommendations

Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide

You Might Also Like