Sanctions Policy and Procedures (OFAC-Aligned; Bridge-Integrated)

1. Purpose and objectives

This Sanctions Policy and Procedures (the “Policy”) establishes minimum controls to prevent the Company’s products and services—including Bridge-enabled services—from being used in violation of applicable economic and trade sanctions laws and regulations.

Minimum control outcomes:

• Screen customers, beneficial owners, and relevant counterparties against applicable sanctions/watchlists.
• Identify, escalate, and resolve potential matches promptly.
• Block/reject transactions and restrict accounts where required.
• Coordinate sanctions actions and reporting with Bridge and other partners per contractual roles.
• Maintain auditable evidence of screening, decisions, and communications.

2. Scope

This Policy applies to:

• All users (individual and business), beneficial owners/controllers, and authorized users.
• All products/transactions offered under the Program (on/off ramps, conversions, custody, payouts).
• All geographies supported by the Program and any cross-border exposures.

3. Regulatory and contractual context

The Company complies with sanctions regimes applicable to its operations and customers, which may include:

• U.S. OFAC sanctions (where applicable),
• UN / EU / UK and other national sanctions regimes (where applicable),
• partner and banking/PSP sanctions requirements.

Where Bridge performs certain compliance functions, the Company will support Bridge by:

• providing accurate and timely customer data necessary for screening,
• escalating suspected sanctions exposure and suspicious activity promptly,
• ensuring required user consents and disclosures are obtained prior to access to Bridge services.

See Bridge developer agreement: Bridge Developer Agreement.

4. Governance and roles

4.1. Sanctions Officer / Compliance Officer responsibilities

The Compliance Officer (or designated Sanctions Officer) is responsible for:

• maintaining sanctions risk assessment and policy controls,
• approving screening methodologies and vendor tools,
• overseeing escalation and decisioning (true match vs false positive),
• ensuring holds/blocks/rejections are executed per law/partner rules,
• ensuring required reports/notifications are made by the responsible party (Company or Bridge).

4.2. Staff responsibilities

• Operations/Support: execute procedures, collect additional information, apply account restrictions as instructed, escalate.
• Engineering/Product: maintain screening integrations, logging, access controls, and reliability.
• Compliance: own triage, investigations, decisions, documentation, and partner coordination.

5. Sanctions risk assessment

The Company maintains a sanctions risk assessment considering:

• customer geographies (residence/incorporation), IP and device location signals,
• expected corridors and counterparties,
• product risk (payouts, cross-border, crypto rails),
• exposure to high-risk jurisdictions or sanctioned regions,
• potential blockchain exposure (wallets associated with sanctioned actors, mixers, darknet markets),
• vendor and partner controls (Bridge, PSPs, banks, analytics providers).

6. Screening requirements

6.1. What is screened

At minimum, the Company’s sanctions controls must cover:

• customers (individuals/businesses),
• beneficial owners/controllers and authorized users (for businesses),
• relevant counterparties where available/required (e.g., payees, payout destinations),
• crypto wallet addresses (where the Company collects or observes them) using blockchain analytics tooling where applicable.

6.2. When screening occurs

Screening is performed:

• At onboarding: prior to activation of Bridge-enabled services.
• On changes: when a user updates name, address, ownership, or key profile attributes.
• Ongoing: on a scheduled basis and/or continuous list updates (configured in the Program Parameters and Definitions).
• Pre-transaction / real-time: where product risk warrants (e.g., payouts, higher-risk corridors).

6.3. Screening data quality standards

The Company implements controls to improve match quality:

• standardized capture of legal names and aliases,
• date of birth and address normalization,
• country codes and transliteration rules,
• data completeness checks for KYB/beneficial ownership.

7. Potential match triage and escalation

7.1. Triage timelines

Potential matches must be triaged within defined SLAs based on severity (see the Program Parameters and Definitions).

7.2. Triage steps

Compliance will:

• review match details (name, DOB, address, identifiers) and list entry specifics,
• request additional information where needed,
• evaluate whether the match is a true match, possible match requiring escalation, or false positive,
• document rationale and evidence.

7.3. Escalation and coordination with Bridge

If a true/likely match is suspected and Bridge controls relevant service access or transaction processing:

• the Company escalates to Bridge immediately with supporting evidence,
• the Company follows Bridge instructions for holds/suspensions where Bridge is the executing party,
• the Company ensures internal restrictions are applied on its side (UI access, payout initiation) as applicable.

8. Blocking, rejecting, and account restrictions

The Company will implement procedures to:

• block (freeze) accounts/transactions where required by applicable sanctions law,
• reject prohibited transactions where blocking is not applicable but processing is prohibited,
• restrict or suspend accounts pending resolution.

Execution steps depend on the operational model (Company vs Bridge actioning). The Company will maintain:

• an internal “kill switch” to prevent further initiation of transactions from the UI,
• administrative controls to place holds on withdrawals/payouts where the Company controls such actions,
• partner escalation procedures where Bridge/PSPs must execute the hold/reject.

9. Wallet and blockchain-specific controls (if applicable)

Where the Program involves crypto addresses:

• wallet addresses provided by users or used for payouts are screened using blockchain analytics (where applicable),
• exposure to sanctioned entities, mixers, and high-risk services is evaluated,
• the Company applies risk-based restrictions, EDD, and escalations for wallet-related red flags.

10. Reporting and notifications (as applicable)

The Company maintains procedures to:

• determine the responsible reporting party (Company vs Bridge) for sanctions reporting obligations,
• support Bridge with timely information when Bridge is responsible for reporting,
• ensure evidence of any report/notification is retained.

11. Recordkeeping and audit trail

The Company retains:

• screening logs (who/what/when, list versions, results),
• triage notes, decisions, and approvals,
• evidence supporting true match/false positive determinations,
• account actions taken (holds, restrictions, closures),
• communications with Bridge and other partners.

Retention period: see the Program Parameters and Definitions.

12. Training

Relevant personnel receive sanctions training at onboarding and at least annually, including:

• sanctions basics and red flags,
• match triage and escalation workflow,
• handling customer communications (including non-disclosure restrictions where applicable),
• crypto-specific sanctions typologies (where applicable).

13. Testing and continuous improvement

The Company performs periodic testing of sanctions controls, including:

• sampling of onboarding decisions and ongoing screening,
• tuning of screening logic (fuzzy matching thresholds),
• review of false positive rates and decision quality,
• tabletop exercises for true-match incidents.

14. Policy governance

• Effective date: See the Program Parameters and Definitions (Program metadata).
• Owner: Program owner / Compliance Officer (see the Program Parameters and Definitions).
• Review: at least annually and upon material change.
• Exceptions: documented and approved by Compliance with compensating controls.