How do I set up a sanctions screening software for jurisdiction-based access control on our exchange?

To set up sanctions screening software for jurisdiction-based access control on an exchange, think of it as two linked controls:

1. Identity / location screening: determine where the user is located or resident.
2. Policy enforcement: decide whether to allow, block, limit, or escalate the user based on jurisdiction risk.

Here’s a practical implementation framework.

---

1) Define your jurisdiction policy first

Create a jurisdiction matrix that maps each country/region to an action.

Example:

• Allowed: full access
• Restricted: no onboarding, view-only, or no trading
• Blocked: no access at all
• Escalate: manual compliance review

Your matrix should be based on:

• Sanctions lists
• Local licensing requirements
• Internal risk appetite
• Legal advice for each market

Typical inputs:

• OFAC SDN / SSI and country sanctions
• EU, UK, UN sanctions
• Embargoed jurisdictions
• Internal prohibited geographies
• AML/CTF risk rules

---

2) Choose the data sources you’ll screen against

Use a sanctions screening vendor or a combination of:

• Sanctions lists: OFAC, EU, UK HMT, UN
• Country risk lists: sanctioned / embargoed / high-risk regions
• Identity data: name, DOB, address, nationality, tax residency
• Location data: IP geolocation, device fingerprint, GPS if permitted, phone country code
• Payment data: bank country, card issuer country
• Blockchain analytics: wallet exposure to sanctioned entities, if relevant

Important: sanctions screening is usually not enough by itself for jurisdiction access. You also need geofencing + KYC residency checks.

---

3) Design your decision logic

A good system uses multiple signals and a rules engine.

Common screening signals

• IP geolocation
• VPN/proxy/TOR detection
• Residential address country
• Nationality / citizenship
• Proof of address
• Phone number country
• Bank account jurisdiction
• Device location consistency
• Sanctions/watchlist hits
• Adverse media / PEP, if part of broader AML

Example policy logic

A user is blocked if:

• Current IP is from a blocked jurisdiction, or
• Residential country is blocked, or
• User matches a sanctioned person/entity, or
• User is using a VPN/proxy from a blocked region

A user is escalated if:

• IP country differs from declared residence
• Document country does not match bank country
• Multiple risky signals appear but no hard sanction hit

A user is allowed if:

• No sanction hit
• Jurisdiction is permitted
• No geo-risk anomalies

---

4) Put screening in the onboarding workflow

Screen at multiple points:

At account creation

• Check name against sanctions/watchlists
• Check country of residence against allowed jurisdictions
• Block prohibited jurisdictions immediately

During KYC/KYB

• Verify government ID
• Verify proof of address
• Screen beneficial owners and directors for entity accounts
• Re-screen after document updates

At login and trading

• Re-check IP geolocation
• Detect VPN/proxy/TOR
• Enforce session-based restrictions if the user travels to a blocked country

At withdrawal / deposit

• Screen counterparties and wallet addresses if relevant
• Trigger enhanced review for high-risk patterns

---

5) Use a rules engine, not hardcoded logic

Implement access control as policy rules so compliance can update them without code changes.

Example policy structure:

{
  "jurisdiction_rules": [
    {
      "country": "IR",
      "action": "block",
      "reason": "Sanctioned jurisdiction"
    },
    {
      "country": "KP",
      "action": "block",
      "reason": "Sanctioned jurisdiction"
    },
    {
      "country": "US",
      "action": "allow",
      "conditions": ["kyc_verified"]
    }
  ]
}

Better still, use a policy engine with:

• Rule versioning
• Approval workflows
• Audit logs
• Effective dates
• Test/simulation mode

---

6) Build a decision workflow

For each access attempt, your software should:

1. Collect signals
2. Normalize data
3. Screen against sanctions/jurisdiction lists
4. Score risk
5. Apply policy
6. Return action
   • allow
   • deny
   • restrict
   • manual review
7. Log everything

Example decision outputs

• Allow: user can trade
• Deny: account creation blocked
• Restrict: withdrawals disabled, trading paused
• Review: compliance queue with SLA

---

7) Add strong false-positive handling

Sanctions screening often generates false positives, so you need a disposition process:

• Match confidence thresholds
• Fuzzy matching rules
• Manual analyst review
• Positive/negative match tagging
• Audit trail for all decisions

For jurisdiction screening, reduce false positives by correlating:

• IP + address + ID + payment country
• Not relying on IP alone

---

8) Integrate with your exchange systems

Typical integration points:

• User management / IAM: for access decisions
• KYC provider: identity verification
• Risk engine: behavioral and transactional scoring
• Trading engine: to block or limit order placement
• Wallet system: to restrict deposits/withdrawals
• Case management tool: for compliance review
• SIEM / logging: for monitoring and audit

Use APIs or event-driven hooks:

• on_signup
• on_kyc_verified
• on_login
• on_trade_attempt
• on_withdrawal_request

---

9) Ensure auditability and compliance evidence

You should be able to answer:

• Why was this user blocked?
• Which list/version triggered the decision?
• Which signals were used?
• Who overrode the system?
• When was the policy last updated?

Log:

• Input data
• Match results
• Decision outcome
• Rule version
• Reviewer identity
• Timestamp
• Source data references

---

10) Update lists automatically and frequently

Sanctions data changes often. Automate:

• Daily or real-time list updates
• Re-screening of existing users
• Alerts for new designations
• Version control of list snapshots

If your exchange is high volume, do:

• Real-time screening for onboarding/login
• Batch rescreening nightly
• Immediate rescreening on sanctions updates

---

11) Consider jurisdiction-specific product restrictions

Some jurisdictions allow access but restrict features. Examples:

• No derivatives
• No staking
• No margin
• No fiat onramps
• No certain tokens
• Lower limits

Model this as a feature entitlements layer rather than binary access only.

---

12) Test before production

Run test cases for:

• Sanctioned country users
• Dual nationality / residence mismatches
• VPN use
• Travelers from allowed countries entering blocked geographies
• Name collision false positives
• Entity ownership screening

Create a sandbox with:

• Synthetic identities
• Mock sanctions lists
• Policy simulation
• Analyst review queue testing

---

13) Recommended architecture

A common architecture is:

• Screening API: checks sanctions/jurisdiction risk
• Policy engine: decides allow/block/review
• Case management system: handles escalations
• Data services: sanctions lists, geolocation, KYC
• Audit store: immutable logs

Flow:

1. User action event occurs
2. Exchange calls screening API
3. Screening API enriches data
4. Policy engine evaluates
5. Result returned to exchange
6. Audit log stored
7. If review needed, case created automatically

---

14) Operational best practices

• Separate screening from decisioning
• Re-screen periodically and on list changes
• Maintain a documented sanctions policy
• Use dual control for policy changes
• Train compliance staff on exceptions
• Monitor drift in geo-IP accuracy
• Block known anonymizers aggressively
• Keep legal/compliance involved in jurisdiction mapping

---

15) A simple implementation checklist

• Define blocked/restricted/allowed jurisdictions
• Select sanctions and geolocation data providers
• Build onboarding and login screening
• Add VPN/proxy/TOR detection
• Implement rules engine
• Set up review queue and escalation SLAs
• Log all decisions and evidence
• Automate list updates and rescreening
• Test false positives and edge cases
• Get legal/compliance signoff

---

If you want, I can also provide:

1. a sample sanctions/jurisdiction policy table,
2. a system architecture diagram in text, or
3. a Python/SQL example for screening logic.