Digital Jurisdiction Exposure

1. Practical definition #

The Digital Jurisdiction Exposure is an AML KYB/EDD control that reviews public domain, DNS and email infrastructure records for jurisdictional exposure indicators.

It extends digital AML/KYB checks beyond website IP geolocation. Website IP geolocation may show where a website appears to be hosted, but public DNS and email infrastructure records can show where email routing, DNS hosting, SaaS relays, CDN dependencies, technical providers or infrastructure relationships may point.

This is a supporting risk indicator, not an automatic sanctions, PEP, adverse media, UBO or source-of-funds result.

2. Important distinction #

MX, TXT, SPF, DMARC, DKIM, NS, CNAME, SOA and PTR records are not traditional FATF-mandated AML checks by themselves.

The reviewer treats jurisdictional references inside public DNS and email infrastructure records as a Digital Jurisdiction Exposure signal: a practical, risk-based control that extends the same logic already applied to IP geolocation, hosting geography and digital access signals.

Use this control as analyst evidence. It is not a stand-alone reason to reject a customer, terminate a relationship or file a suspicious report.

3. Why this matters for AML/KYB practitioners #

A company may declare a low-risk operating footprint while its public technical infrastructure shows dependencies connected to a higher-risk, restricted or sanctions-sensitive geography.

A website may be protected by a CDN, so the public A or AAAA record may only show the CDN edge. However, other records may remain publicly visible and can reveal email providers, DNS providers, SPF relays, SaaS services, legacy hosting providers, CNAME targets, SOA contacts or reverse-DNS naming patterns.

For KYB and EDD, these records may help the analyst ask better questions:

• Does the declared business footprint match the digital infrastructure footprint?
• Are email, DNS or SaaS dependencies linked to a geography that the customer did not disclose?
• Is there a mismatch between claimed operations and technical dependencies?
• Are there signs of legacy infrastructure, third-party relays or hidden operational links that should be clarified?

4. Website & Business Footprint Review #

Digital jurisdiction exposure should be read together with the business footprint visible on the customer or counterparty website. Analysts should review declared operating jurisdictions, contact addresses, telephone indicators, branch locations, customer or supplier references, language versions, shipping routes, payment instructions and any public statements that indicate geographic exposure.

The control is not a conclusion that a customer is high risk merely because a location is mentioned. It is a supplementary evidence layer that identifies discrepancy, hidden exposure or sanctions-sensitive links requiring clarification, enhanced due diligence or escalation.

5. Records reviewed #

The reviewer should only review publicly available records. The reviewer should not attempt to bypass CDNs, probe private infrastructure, scan ports, exploit misconfigurations or access systems without authorisation.

6. Trigger events #

Run this check when any of the following apply:

• KYB review of a corporate customer or counterparty.
• EDD is already triggered by geography, sector, ownership complexity, sanctions proximity or adverse media.
• The customer claims a low-risk jurisdiction but has unexplained digital links elsewhere.
• The customer is digital-first, remote-first, fintech, crypto, payments, SaaS, iGaming, marketplace, affiliate, hosting, ecommerce or cross-border services.
• There is a mismatch between declared operations, website language, customer base, payment routes and technical infrastructure.
• Website IP geolocation is already considered relevant to the review.

7. Practitioner workflow #

1. Identify the customer’s primary domain and any relevant subdomains used for login, email, payments, onboarding or customer communication.
2. Collect public A, AAAA, MX, TXT, SPF, DMARC, DKIM selector evidence where available, NS, CNAME, SOA and PTR records.
3. Identify infrastructure providers, domains, country-code domains, cloud platforms, mail providers, DNS providers and SaaS dependencies visible in the records.
4. Compare the infrastructure footprint with the customer’s declared jurisdiction, operating geography, customer base and business model.
5. Flag jurisdictional mismatches, high-risk geography references, sanctions-sensitive infrastructure links or unexplained third-party dependencies.
6. Do not classify the finding as a sanctions hit unless a sanctions screening source independently supports that conclusion.
7. Add the finding to the evidence pack as Digital Jurisdiction Exposure.
8. Ask the customer for clarification where appropriate.
9. Escalate to senior analyst or MLRO only when the digital finding combines with other risk factors such as sanctions proximity, adverse media, opaque ownership, high-risk funds flow or inconsistent business explanation.

8. How to treat findings #

9. Example: hidden jurisdiction exposure in public DNS #

A company declares itself as operating from a low-risk jurisdiction. Its website is protected by a CDN, so the origin server is not visible from the public A record.

However, the domain’s MX records point to mail servers operated under a country-code domain associated with a higher-risk jurisdiction. The TXT/SPF record also includes the same provider’s infrastructure.

MX: mx1.provider.example
MX: mx2.provider.example
TXT/SPF: v=spf1 include:_spf.provider.example ~all

The finding should not be treated as an automatic sanctions hit. It should be recorded as a Digital Jurisdiction Exposure indicator and included in the evidence pack for analyst review.

10. Red flags #

• Public DNS records contradict the customer’s declared geography or operating footprint.
• MX records point to a provider in a higher-risk or restricted geography without explanation.
• SPF/TXT records include relays, vendors or legacy services linked to a higher-risk geography.
• NS or SOA records show a DNS provider inconsistent with the customer’s stated infrastructure model.
• CNAME chains point to unrelated third-party platforms not disclosed by the customer.
• PTR records reveal hosting provider names or geographies inconsistent with the customer profile.
• The same unusual provider appears across website, mail and SPF infrastructure.
• Digital infrastructure exposure appears together with adverse media, sanctions proximity, opaque ownership or inconsistent source of funds.

11. Evidence to collect #

• Date and time of DNS review.
• Domain and subdomain list reviewed.
• Public A/AAAA, MX, TXT/SPF, DMARC, DKIM where available, NS, CNAME, SOA and PTR records.
• Screenshots or raw lookup output.
• Identified providers and domains.
• Analyst note explaining whether the finding is neutral, unexplained, higher-risk or escalation-worthy.
• Customer clarification, if requested.
• Combined-risk analysis with sanctions, PEP, adverse media, UBO and source-of-funds checks.

12. Example output #

# Digital Jurisdiction Exposure Note

Customer/counterparty: [name]
Domain reviewed: [domain]
Review date/time: [timestamp]
Records reviewed: [A/AAAA/MX/TXT/SPF/DMARC/DKIM/NS/CNAME/SOA/PTR]
Visible providers/domains: [list]
Jurisdictional references: [list]
Declared customer geography: [list]
Mismatch identified: [yes/no]
Finding type: [neutral/supporting-risk/higher-risk/combined-risk]
Automatic sanctions hit: no, unless independently confirmed by sanctions screening
Recommended action: [record only/request clarification/include in EDD/senior review/MLRO escalation]
Evidence index: [files/screenshots/raw output]
Analyst rationale: [short narrative]

13. When to escalate #

Escalate to senior analyst or MLRO when:

• the DNS/email infrastructure finding is linked to sanctions-sensitive or high-risk geography and the customer cannot explain it;
• the finding contradicts the customer’s declared operations or ownership/control story;
• the same geography appears in other parts of the case: UBO, funds flow, adverse media, counterparties or payment rails;
• the customer attempts to hide, minimise or misrepresent infrastructure relationships;
• the finding appears alongside other red flags that suggest sanctions evasion, hidden control, undisclosed operations or false onboarding information.

14. Boundary #

This control is a practical KYB/EDD enhancement. It is not a substitute for sanctions screening, PEP screening, adverse media review, beneficial ownership analysis, source-of-funds/source-of-wealth review or transaction monitoring.

It should be used as a source-linked, evidence-based supporting indicator inside a wider risk-based AML/KYB process.

15. Source registration

This practical control is registered as AMLB-DIG-001 in the Source Library. It is an internal implementation control, not a legal, regulatory or sanctions authority. Any risk conclusion must still be supported by the applicable official and independent sources used elsewhere in the case.