Module 5 — Industry Scenarios (PSP, Marketplace, Fintech/Crypto, Freight Forwarder)

Goal of this module

After this module, you should be able to:

• Recognize the most common sanctions risk scenarios in four industries: PSP, Marketplace, Fintech/Crypto, and Freight Forwarder.
• Identify which sanctions type is at play (list-based, country/region, sectoral, secondary).
• Apply the right control response: Stop → Escalate → Document.
• Understand what data and evidence matter for faster, defensible decisions.

---

How to use this module

Each scenario follows a consistent structure:

• What’s happening (realistic story)
• Why it matters (sanctions risk type + business impact)
• Red flags (what employees should notice)
• Controls that should trigger (screening + rules)
• What you do (Stop–Escalate–Document)
• Evidence to capture (what Compliance needs)

---

Scenario set A — PSP (Payments Service Provider)

Scenario A1 — Merchant onboarding: clean name, risky ownership

What’s happening:
A new merchant applies for onboarding. Company name screens clean. During KYB, a beneficial owner shows a close match to a designated person.

Why it matters:
List-based sanctions + ownership/control risk. A non-listed company may be restricted if owned/controlled by a designated party.

Red flags:

• UBO name match (especially with overlapping DOB/nationality/address)
• complex ownership chain with offshore entities
• unwillingness to provide UBO evidence

Controls that should trigger:

• onboarding screening for UBOs/principals
• KYB risk scoring and enhanced due diligence workflow
• “UBO mismatch / missing data” escalation rule

What you do (Stop–Escalate–Document):

• Stop: do not activate the merchant account or settlement.
• Escalate: open a sanctions case with UBO screening output and KYB documents.
• Document: log the hold, what checks ran, and what data was missing.

Evidence to capture:

• UBO details (name variants, DOB, nationality, address)
• ownership percentages and structure diagram (if available)
• merchant incorporation details + registry extracts
• screening output (matched record + list source)

---

Scenario A2 — Transaction screening: payer/payee look fine, beneficiary bank doesn’t

What’s happening:
A cross-border transfer is initiated. Sender and recipient look clean, but the beneficiary bank is in a high-risk corridor or restricted region.

Why it matters:
Country/region-based sanctions and routing risk. Some restrictions apply due to geography and financial routing even without listed parties.

Red flags:

• beneficiary bank country conflicts with stated purpose
• repeated edits to beneficiary details
• corridor inconsistent with customer profile

Controls that should trigger:

• transaction screening + corridor risk rules
• beneficiary bank country restrictions
• routing change monitoring (rapid beneficiary edits)

What you do:

• Stop: hold the transfer.
• Escalate: provide corridor details, beneficiary bank identifiers, and customer profile context.
• Document: record the hold reason and any previous similar attempts.

Evidence to capture:

• SWIFT/BIC, bank name and country, intermediary banks
• transaction metadata (amount, currency, timestamps)
• customer KYC profile + expected corridor
• communications/support tickets if customer requested reroute

---

Scenario A3 — Refund/chargeback: value flows to a newly listed party

What’s happening:
A merchant is later found to be designated, or a beneficial owner becomes listed. A chargeback/refund is pending.

Why it matters:
Ongoing screening and “making funds available” risk. Refunds and chargebacks can provide value to designated parties.

Red flags:

• rescreen hit on an existing merchant or principal
• high urgency requests to release refunds
• pressure from merchant or internal teams

Controls that should trigger:

• rescreening alerts
• account status change workflow (restricted)
• payout/refund hold rule

What you do:

• Stop: hold refunds/payouts as required.
• Escalate: treat as potentially high severity; Compliance may require lookback.
• Document: document designation timing vs transaction timing.

Evidence to capture:

• timestamps: designation date vs refund initiation
• list source and matched identifiers
• refunds/chargebacks list and amounts
• account ownership/control details

---

Scenario set B — Marketplace

Scenario B1 — Seller payout: seller is clean, payout beneficiary is not

What’s happening:
A marketplace seller account screens clean, but the payout beneficiary (bank account holder) triggers a sanctions close match.

Why it matters:
List-based sanctions + indirect value. Payouts are direct “funds made available.”

Red flags:

• beneficiary name mismatch vs seller legal name
• frequent beneficiary changes before payout
• beneficiary in higher-risk geography

Controls that should trigger:

• payout beneficiary screening
• beneficiary change velocity rule
• seller payout hold + escalation

What you do:

• Stop: pause payout release.
• Escalate: include seller profile + beneficiary details + history of payout changes.
• Document: record the timeline and all beneficiary change events.

Evidence to capture:

• beneficiary name, bank details, country
• seller KYC/KYB + trading names
• payout history and beneficiary change logs
• any seller communications requesting changes

---

Scenario B2 — Restricted destination shipping (non-listed parties)

What’s happening:
Buyer and seller are not listed. The shipping address is in a restricted region, or the buyer requests rerouting via a third country.

Why it matters:
Country/region-based sanctions. Shipping/delivery can trigger restrictions even without listed parties.

Red flags:

• shipping address in restricted area
• repeated address changes near shipment
• “forwarder address” used to obscure final destination

Controls that should trigger:

• shipping destination blocklist
• reroute detection
• product category restrictions (if controlled goods)

What you do:

• Stop: stop fulfillment and associated payment release.
• Escalate: include order details + destination + rerouting attempts.
• Document: log the policy trigger and customer requests.

Evidence to capture:

• original and updated shipping addresses
• order SKU/category and description
• fulfillment warehouse location (if relevant)
• customer messages requesting reroute

---

Scenario B3 — Digital services delivery into restricted geographies

What’s happening:
A platform sells digital services (software access, subscriptions, downloads). The user accesses from a restricted geography via IP/device signals.

Why it matters:
Country/region restrictions + export-controls-adjacent risk. Digital delivery may be treated as a cross-border service/export.

Red flags:

• repeated logins from restricted geographies
• billing country and usage location inconsistent
• sudden changes in account profile data

Controls that should trigger:

• geofencing access controls (if policy mandates)
• account review for conflicting geo signals
• risk-based temporary access restriction

What you do:

• Stop: apply temporary access restriction (per policy) and hold refunds.
• Escalate: provide geo evidence and account history.
• Document: record signals and what control triggered.

Evidence to capture:

• IP/device geo signals, timestamps (as permitted by privacy policy)
• billing/shipping/residence country data
• account change history (email, address, payment method)
• product/service delivered

---

Scenario set C — Fintech/Crypto

Scenario C1 — Wallet/customer name is clean, blockchain exposure is not

What’s happening:
A customer wants to cash out crypto to fiat. Name screens clean. Blockchain analytics (if used) flags exposure to sanctioned services or addresses.

Why it matters:
List-based + secondary risk + commercial risk. Exposure to sanctioned actors/services can lead to banking partner de-risking even beyond strict legal scope.

Red flags:

• funds sourced from high-risk services
• repeated small inbound transfers then a large cash-out
• customer refuses source-of-funds explanation

Controls that should trigger:

• crypto transfer risk scoring / blockchain analytics alerts
• enhanced due diligence (SoF/SoW) workflow
• cash-out hold pending review

What you do:

• Stop: hold the cash-out.
• Escalate: include the alert details and requested SoF info.
• Document: record the basis for hold and customer communications.

Evidence to capture:

• transaction hashes and risk indicators (as your tooling provides)
• customer KYC profile and expected activity
• SoF/SoW information provided (or refusal)
• linked accounts and withdrawal destinations

---

Scenario C2 — Sanctions evasion pattern: repeated retries and beneficiary changes

What’s happening:
A user repeatedly fails transfers, then tries different beneficiaries, different corridors, and asks support for workarounds.

Why it matters:
Evasion risk. Even if the person is not listed, this pattern increases the probability of sanctions breach and partner de-risking.

Red flags:

• multiple failed attempts across corridors
• beneficiary changes shortly before execution
• support requests: “How can I make this go through?”

Controls that should trigger:

• velocity rules on failed transfers
• beneficiary change monitoring
• account restriction triggers

What you do:

• Stop: restrict transfers and place holds as required.
• Escalate: case creation with full pattern timeline.
• Document: document attempted workarounds and your response.

Evidence to capture:

• timeline of retries, corridors, beneficiaries
• support conversation excerpts (verbatim, where allowed)
• device/account linkage signals
• relevant screening and transaction monitoring outputs

---

Scenario C3 — High-risk sector: trade finance-like features in a fintech product

What’s happening:
A fintech offers invoice financing or advance payouts to merchants engaged in high-risk cross-border trade.

Why it matters:
Sectoral risk and secondary sanctions exposure. Financing-like products can intensify sanctions sensitivity.

Red flags:

• goods/services linked to restricted sectors
• unusual third-party payments
• merchants in high-risk corridors without credible documentation

Controls that should trigger:

• enhanced underwriting for high-risk merchant sectors
• corridor restrictions and EDD
• financing feature approval controls

What you do:

• Stop: pause financing activation or disbursement.
• Escalate: provide merchant trade profile, counterparties, and corridor details.
• Document: record the basis and decision outcome.

Evidence to capture:

• merchant business model and trade counterparties
• invoices/contracts and goods descriptions
• shipping/incoterms (if available)
• screening outputs for counterparties

---

Scenario set D — Freight Forwarder

Scenario D1 — Shipping to restricted region (no listed parties)

What’s happening:
A client requests shipment to a restricted region. The client is not listed. They propose a “transshipment” route via a third country.

Why it matters:
Country/region-based sanctions + evasion risk. Routing can create prohibited delivery or facilitation.

Red flags:

• vague end-destination documentation
• unusual routing that increases complexity
• forwarder address or multiple intermediaries

Controls that should trigger:

• destination and route screening
• end-user/end-use documentation requirements
• escalation for transshipment patterns

What you do:

• Stop: pause shipment booking and cargo release.
• Escalate: include route plan, end-destination, and documentation gaps.
• Document: record the route change request and decision.

Evidence to capture:

• shipper/consignee and end-user details
• full routing plan (ports, carriers, intermediaries)
• commodity description and HS codes (if available)
• documents: invoice, packing list, end-use statement

---

Scenario D2 — Dual-use goods indicators

What’s happening:
A customer ships “industrial components” with vague descriptions. The cargo appears dual-use or inconsistent with the customer’s profile.

Why it matters:
Export-controls-adjacent + sanctions program risk. Dual-use items often intersect with sanctioned programs.

Red flags:

• generic product descriptions
• mismatch between customer business and goods
• urgent requests and reluctance to provide specs

Controls that should trigger:

• controlled goods screening (HS code/category flagging)
• request-for-information workflow
• hold pending documentation

What you do:

• Stop: pause shipment acceptance.
• Escalate: include commodity details and documentation gaps.
• Document: record what was requested and what was provided.

Evidence to capture:

• HS codes, technical specifications, datasheets
• shipper/consignee/end-user identities
• destination and end-use statement
• prior shipment history (if available)

---

Scenario D3 — Listed entity appears in shipping documents

What’s happening:
A listed entity name appears in shipping documents (consignee, notify party, or intermediary) even though the contracting party is different.

Why it matters:
List-based sanctions. Indirect involvement can still be prohibited facilitation.

Red flags:

• listed name appears as “notify party”
• discrepancies between invoice party and consignee
• last-minute document changes

Controls that should trigger:

• document-based screening (names on shipping docs)
• mismatch checks (contracting party vs consignee)
• high-priority escalation

What you do:

• Stop: hold shipment.
• Escalate: provide all documents and the match details.
• Document: keep a full audit trail of document versions.

Evidence to capture:

• all versions of shipping docs (BL/AWB, invoice, packing list)
• match output and identifiers
• route and carrier details
• customer communication history

---

Cross-industry “Stop–Escalate–Document” cheat sheet

STOP (contain risk)

• Hold onboarding activation, payouts, refunds, shipments, access, or transfers (as relevant).
• Prevent retries/workarounds and preserve evidence.

ESCALATE (decision-ready package)

• Provide match output + identifiers + transaction/order/shipment context + geography + history.

DOCUMENT (audit-ready)

• Timestamps, actions taken, who was notified, what decision was made, and why.

---

Knowledge check (6 questions)

1. A counterparty must be listed for a shipment/payment to be restricted. True or false?
2. Ownership/control can make a non-listed entity risky under list-based sanctions. True or false?
3. Shipping destination and routing can trigger sanctions risk even without a name match. True or false?
4. Payout beneficiaries should be screened separately from marketplace seller names. True or false?
5. For crypto/fintech, “clean KYC” always means “low sanctions risk.” True or false?
6. If you stop activity due to a sanctions signal, documentation is optional if Compliance takes over. True or false?

Answers

1. False. Country/region restrictions and routing can apply without listed parties.
   
2. True. Ownership/control links can extend restrictions beyond the listed name.
   
3. True. Geography and transshipment patterns are key risk drivers.
   
4. True. Payouts are direct value transfer and beneficiaries can differ from account owners.
   
5. False. Activity patterns and transaction context can reveal additional risk.
   
6. False. Documentation is essential for auditability and defensibility.

---