KYC/AML & Compliance

How compliance affects API integrations: what is screened, what can pause or refund an order, and what integrators are responsible for.

The model

The API does not require end-user registration or direct KYC collection. Compliance is enforced at the transaction level:

• Real-time screening of addresses and IPs against sanctions lists (OFAC, EU, UN) and known-illicit clusters (mixers, darknet markets)
• Transaction pattern analysis for suspicious activity
• Risk-based assessment of amounts and frequency
• Blockchain analysis of source and destination exposure

Applies to DeFi orders too

DeFi execution uses permissionless protocol infrastructure, so protocol-level KYC is not present by default — but platform-level screening (blocklists, sanctions/OFAC SDN checks, and optional pre-screening) still applies, and integrators remain responsible for AML/sanctions obligations in their jurisdictions.

How compliance surfaces in the API

Surface	Behavior
POST /pre_screening/	Proactive check before order creation. A blocked user returns HTTP 200 with status: "failed"
PENDING KYC order status	An in-flight order was routed to enhanced due diligence — see Order Lifecycle. It resumes (PAID → … → COMPLETED) or refunds (INITIATED REFUND → REFUNDED)
Refund path	Orders failing compliance are refunded to refund_address — collect it (and refund_address_extra_id where relevant) at creation

Transaction limits

Limits apply per user/IP and per transaction, and large or unusual transactions trigger enhanced due diligence. The concrete thresholds are risk-based and change without notice — they are not published as fixed numbers and are not exposed as API fields. Use pre-screening with the actual amount to check eligibility for a specific transaction, and handle PENDING KYC gracefully in your UI.

Prohibited use

The service must not be used for money laundering, terrorist financing, sanctions evasion, fraud, darknet-market flows, or laundering ransomware proceeds. Transactions may be restricted for users from sanctioned or FATF high-risk jurisdictions. Violations lead to holds, refusal of service, and reporting to authorities where required.

Integrator responsibilities

When integrating the API you are expected to:

• Pre-screen flows where you hold user context (IP, source address) via POST /pre_screening/
• Keep records of transaction attempts, screening results, and compliance decisions, as required by the laws applicable to you
• Report suspicious activity to your competent authorities within required timeframes, and preserve related records
• Not attempt to bypass screening outcomes (e.g. retrying a blocked address from different IPs)

Regulatory alignment

The program follows FATF recommendations, EU AML directives, and applicable local regulations, with continuous monitoring of sanctions lists and regulatory changes. Records are retained as required by applicable law.

Contact

Compliance inquiries: support@n.exchange — mark the subject "Compliance".

Legal disclaimer

This page describes platform practices for integrators; it is not legal advice. Consult qualified counsel for the requirements that apply to your business and jurisdiction.

Next steps

• Pre-screening — the compliance endpoint
• Order Lifecycle — PENDING KYC and refund flows