> For the complete documentation index, see [llms.txt](https://aipaywithcrypto.gitbook.io/whitepaper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://aipaywithcrypto.gitbook.io/whitepaper/ai-pay-with-crypto-whitepaper/11-compliance-and-regulatory-framework.md).

# 11 — COMPLIANCE & REGULATORY FRAMEWORK

APC operates across digital-asset payments, merchant acceptance, conversion, clearing, settlement, card-based commerce, and emerging Agent-initiated payment infrastructure.

These activities may intersect with different regulatory frameworks depending on the product, transaction type, asset, jurisdiction, payment route, participating entity, and role performed by APC or an external service provider.

APC therefore applies a risk-based and jurisdiction-sensitive compliance framework designed to support payment integrity, financial-crime controls, transaction traceability, and responsible access to its infrastructure.

The framework is informed by internationally recognized principles applicable to payment services and virtual-asset activity, including risk-based AML/CFT treatment of virtual assets and VASPs. FATF guidance specifically addresses stablecoins, peer-to-peer transactions, licensing and registration, supervisory cooperation, and the Travel Rule.

Compliance requirements are implemented according to applicable law and the responsibilities of the regulated or supervised entities participating in each payment flow.

&#x20;

### 11.1 — Compliance Principles

APC's compliance architecture is based on six core principles:

| Principle                      | Application                                                                                                                            |
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- |
| Risk-Based Controls            | Compliance measures are applied according to customer, merchant, transaction, asset, jurisdiction, and channel risk                    |
| Identity & Entity Verification | Applicable users, merchants, businesses, and counterparties may be subject to KYC / KYB controls                                       |
| Transaction-Level Monitoring   | Digital-asset transactions may be screened and monitored for financial-crime and blockchain-related risk                               |
| Jurisdictional Compliance      | Product and transaction availability may vary according to local legal and regulatory requirements                                     |
| Partner Responsibility         | Regulated activities performed by external providers remain subject to the authorization and compliance obligations of those providers |
| Traceability & Auditability    | Payment, blockchain, compliance, clearing, and settlement records are maintained or associated where applicable                        |

These principles operate across APC's payment infrastructure rather than being limited to a single compliance checkpoint.

&#x20;

### 11.2 — Customer, Merchant & Entity Due Diligence

Access to APC products and transaction capabilities may require verification according to the nature of the participant and applicable regulatory requirements.

#### Individual Users

Applicable controls may include:

<figure><img src="https://3794860345-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOKxhjRwcjf3PPe3LhOKg%2Fuploads%2FalWCkPIFhOLbtrDbaWz5%2Fimage.png?alt=media&amp;token=792b5bf1-fd2f-4836-bedf-df2e747264fc" alt=""><figcaption></figcaption></figure>

Merchants & Businesses

Applicable controls may include:

Enhanced Due Diligence

<figure><img src="https://3794860345-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOKxhjRwcjf3PPe3LhOKg%2Fuploads%2FnqJ3dDzbfgmkKX1yHkXp%2Fimage.png?alt=media&amp;token=b252b554-2b71-4738-ada9-a3df9efea60f" alt=""><figcaption></figcaption></figure>

Higher-risk relationships or transactions may require additional review depending on factors such as jurisdiction, transaction behavior, business activity, ownership structure, source of funds or assets, sanctions exposure, or other identified risk indicators.

Verification requirements may vary according to the product, market, transaction profile, and requirements of participating regulated providers.

<figure><img src="https://3794860345-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOKxhjRwcjf3PPe3LhOKg%2Fuploads%2F4xVQCbNW3Hq0tbVQvUjz%2Fimage.png?alt=media&amp;token=75750e09-13ca-47f0-bc45-cce50d7d52dc" alt=""><figcaption></figcaption></figure>

### 11.3 — AML / CFT Framework

APC's compliance architecture is designed to support controls relating to anti-money laundering and counter-terrorist financing (AML/CFT) across applicable digital-asset and payment activity.

FATF applies a risk-based approach to virtual-asset activity and expects covered VASPs to be subject to relevant AML/CFT measures applicable to financial institutions. Its framework also specifically addresses stablecoins and the Travel Rule.

APC's applicable AML/CFT controls may include:

* Customer and merchant due diligence
* Wallet and blockchain-address screening
* KYT and transaction monitoring
* Sanctions and restricted-party screening
* Transaction risk assessment
* Risk-based transaction limits
* Enhanced review of higher-risk activity
* Restriction or rejection of transactions
* Recordkeeping
* Escalation and reporting, where and when required by applicable law

The nature and extent of these controls depend on the transaction, service, jurisdiction, risk profile, and regulatory responsibilities of the participating entities.

&#x20;

### 11.4 — KYT & Blockchain Transaction Monitoring

Because APC connects blockchain-based payment execution with downstream merchant settlement, compliance controls extend beyond customer onboarding.

#### Applicable digital-asset transactions may be evaluated using Know Your Transaction (KYT), blockchain-address screening, transaction monitoring, and risk signals.

<figure><img src="https://3794860345-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOKxhjRwcjf3PPe3LhOKg%2Fuploads%2FMEs1r38S65IgW4gnrIzU%2Fimage.png?alt=media&amp;token=948bb328-bb29-4845-9f94-c4e004b8d822" alt=""><figcaption></figcaption></figure>

&#x20;

Risk assessment may consider transaction characteristics, wallet activity, blockchain exposure, transaction patterns, jurisdiction, asset type, counterparty information, and other available indicators.

This risk-based approach is consistent with the broader FATF framework for virtual-asset activity, which emphasizes assessing and mitigating ML/TF risks rather than applying identical controls indiscriminately to every activity.

&#x20;

### 11.5 — Sanctions & Restricted Activity

APC's compliance framework is designed to support applicable sanctions, restricted-party, and prohibited-activity controls.

Depending on the product and jurisdiction, screening and controls may apply to:

&#x20;

<figure><img src="https://3794860345-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOKxhjRwcjf3PPe3LhOKg%2Fuploads%2FghXktQLI33UyHZcqoi7v%2Fimage.png?alt=media&amp;token=1ecf49ac-f0b9-494f-9ab5-d4eb91744def" alt=""><figcaption></figcaption></figure>

Where applicable risk or restrictions are identified, transactions or services may be subject to additional review, restriction, suspension, rejection, or other action required by law or applicable partner requirements.

APC may also restrict access to products, assets, networks, or payment channels in jurisdictions where provision of the applicable service would conflict with legal, regulatory, sanctions, or partner requirements.

&#x20;

### 11.6 — Stablecoin & Digital-Asset Payment Compliance

Stablecoin payments combine characteristics of blockchain-based value transfer with traditional payment and settlement infrastructure.

APC therefore treats the on-chain payment leg and downstream conversion/settlement leg as distinct but connected compliance environments.

Cross-border stablecoin arrangements can raise issues involving legal certainty, AML/CFT, market integrity, data protection, consumer protection, prudential considerations, and payment-system integrity. International guidance also recognizes substantial differences between jurisdictions in their treatment of stablecoins.

Accordingly, support for a particular stablecoin does not by itself mean that the asset or related service is available without restriction in every APC market.

Availability may depend on:

&#x20;

<figure><img src="https://3794860345-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOKxhjRwcjf3PPe3LhOKg%2Fuploads%2FM2SI6ccsgdmY8F3g3D1u%2Fimage.png?alt=media&amp;token=50155377-c0ba-4f02-b1d9-198c1a0eda8b" alt=""><figcaption></figcaption></figure>

### 11.7 — Travel Rule & Transfer Information

Where applicable to a transaction, entity, or jurisdiction, digital-asset transfers may be subject to requirements concerning the collection, transmission, verification, or retention of information associated with the originator and beneficiary.

FATF's virtual-asset framework includes application of the Travel Rule to relevant virtual-asset service providers and continues to identify implementation as an important area of global VA/VASP compliance.

Travel Rule obligations may vary by jurisdiction, transaction structure, counterparty type, applicable thresholds, and regulatory classification.

APC and participating service providers may therefore apply additional information requirements or transaction controls where necessary to satisfy applicable transfer-information obligations.

&#x20;

### 11.8 — Merchant & Payment Acceptance Compliance

Merchant payment infrastructure introduces compliance requirements beyond blockchain transaction screening.

Applicable merchant controls may include:

| Control                      | Purpose                                                           |
| ---------------------------- | ----------------------------------------------------------------- |
| KYB                          | Verify merchant or business identity                              |
| Beneficial Ownership         | Identify relevant ownership or controlling parties where required |
| Business Activity Review     | Assess merchant activity and eligibility                          |
| Restricted Activity Controls | Prevent access by prohibited or unsupported business categories   |
| Transaction Monitoring       | Identify unusual or higher-risk payment activity                  |
| Fraud Controls               | Detect transaction and merchant-related fraud indicators          |
| Settlement Controls          | Apply requirements associated with acquiring and payout channels  |
| Ongoing Review               | Reassess merchant relationships where required                    |

Merchant acceptance, acquiring, and settlement requirements may differ between markets and payment channels.

&#x20;

### 11.9 — Conversion, Liquidity & Settlement Compliance

APC's payment architecture may require conversion between digital assets and merchant-facing settlement currencies.

The compliance framework therefore extends across:

&#x20;

<figure><img src="https://3794860345-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOKxhjRwcjf3PPe3LhOKg%2Fuploads%2F5JuwkpCitJFOfLaTb90p%2Fimage.png?alt=media&amp;token=c2c3c206-5830-4dd5-b519-7bb740490405" alt=""><figcaption></figcaption></figure>

&#x20;

Conversion, acquiring, banking, payout, and settlement activities may involve external providers subject to their own regulatory authorizations and compliance obligations.

Where applicable payment regulations require safeguarding or equivalent protection of customer funds, those obligations belong to the entity performing the relevant regulated activity under the applicable jurisdictional framework. For example, regulated payment and e-money institutions in the UK are subject to specific safeguarding requirements designed to protect relevant customer funds.

APC should therefore not make a universal claim that all funds are “safeguarded” unless the specific entity, account structure, jurisdiction, and regulatory basis have been confirmed.

&#x20;

### 11.10 — Cross-Border Payment Compliance

APC connects digital-asset payment infrastructure with merchant payment and settlement environments across multiple markets.

Cross-border payment activity may involve different legal and regulatory requirements at multiple points in the transaction:

A payment route may therefore be subject to requirements concerning AML/CFT, sanctions, payment services, digital assets, stablecoins, foreign exchange, data protection, consumer protection, tax, reporting, or other financial regulations.

International guidance recognizes that stablecoin regulatory approaches remain jurisdiction-dependent and emphasizes the importance of appropriate regulation, supervision, and oversight for cross-border arrangements.

APC may modify or restrict payment routes according to applicable requirements and partner availability.

&#x20;

### 11.11 — APC Card Compliance & Payment Data Security

APC Card —&#x20;

Card-based payments introduce additional requirements relating to card issuance, processing, acquiring, transaction security, payment data, fraud controls, and card-network rules.

Applicable responsibilities may be distributed among:

APC

→ Payment / wallet integration

ISSUING PARTNER

→ Card issuance and cardholder requirements

PROCESSOR

→ Authorization and transaction processing

CARD NETWORK

→ Network rules and clearing infrastructure

ACQUIRER

→ Merchant-side card acceptance

Where payment-card account data falls within the applicable cardholder data environment, relevant entities may be subject to PCI DSS requirements according to their role and technical scope.

PCI DSS establishes baseline technical and operational requirements for protecting payment account data and applies to entities that store, process, or transmit cardholder or sensitive authentication data, as well as entities capable of affecting the security of that environment.

APC should not be described as “PCI DSS certified/compliant” in the Whitepaper unless the applicable certification or compliance scope has been independently confirmed.

&#x20;

### 11.12 — APC Agent Pay Compliance

STATUS: <mark style="color:red;">IN DEVELOPMENT</mark>

APC Agent Pay introduces a new transaction origin: an authorized AI Agent acting under delegated authority.

The compliance model is intended to extend existing payment controls rather than create a separate regulatory environment.

<figure><img src="https://3794860345-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOKxhjRwcjf3PPe3LhOKg%2Fuploads%2F4GG3wap6qfDi1S5I9lWj%2Fimage.png?alt=media&amp;token=463ae0cb-28bb-45a0-a8a5-9cc8df936d0f" alt=""><figcaption></figcaption></figure>

\
Agent authorization does not replace the underlying compliance requirements applicable to the payment.

Agent-initiated transactions remain subject to applicable identity, transaction, sanctions, payment, settlement, and jurisdictional controls.

&#x20;

### 11.13 — APC Insurance Compliance

STATUS: <mark style="color:blue;">PLANNED</mark>

APC Insurance is designed as a transaction protection layer for eligible stablecoin payments.

Insurance coverage is intended to be provided through participating regulated insurance partners, with APC integrating applicable payment, transaction, settlement, and coverage infrastructure.

Insurance-related responsibilities may include:

&#x20;

<figure><img src="https://3794860345-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOKxhjRwcjf3PPe3LhOKg%2Fuploads%2FFLDnIXWxSyajpq1PwqAX%2Fimage.png?alt=media&amp;token=e3b2f78d-899b-4f16-9d26-68a5fee3c3b8" alt=""><figcaption></figcaption></figure>

The availability of insurance will be subject to applicable insurance regulations, underwriting requirements, policy terms, eligibility criteria, exclusions, limits, premiums, jurisdictional availability, and partner requirements.

APC does not represent that insurance coverage currently exists unless a specific policy or protection agreement has been issued. APC is not an insurer unless expressly identified as such and legally authorized.

&#x20;

### 11.14 — Data Protection & Privacy

Compliance extends beyond financial-crime controls.

Personal and transaction information processed through APC products may be subject to applicable privacy and data-protection requirements.

Depending on the service, information may be processed for:

* &#x20;Identity Verification
* Account Administration
* Payment Processing
* AML / Compliance
* Fraud & Risk Prevention
* Security
* Settlement & Reconciliation
* Customer Support
* Legal / Regulatory Requirements

The collection, processing, sharing, retention, international transfer, and protection of personal information are addressed in greater detail in the applicable APC Privacy Policy.

&#x20;

### 11.15 — Security & Operational Resilience

APC's compliance framework is supported by technical and operational controls designed to protect payment infrastructure and transaction integrity.

Relevant controls may include:

&#x20;

<figure><img src="https://3794860345-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOKxhjRwcjf3PPe3LhOKg%2Fuploads%2FLOfaHxm7selnDWYqgSOZ%2Fimage.png?alt=media&amp;token=359921fc-cf29-4c7c-a333-a94db7f6f553" alt=""><figcaption></figcaption></figure>

Payment regulation can impose operational and security requirements in addition to financial-crime controls. For example, regulated payment-service frameworks include requirements intended to make payment services safer and more resilient.

Specific internal security configurations, detection thresholds, credentials, keys, and other security-sensitive information are not publicly disclosed.

### 11.16 — Regulatory & Partner Responsibility Model

APC operates within an ecosystem involving multiple technical, financial, payment, blockchain, and regulated service providers.

The regulatory responsibility associated with a transaction therefore depends on the function being performed, not simply the APC brand through which the transaction is accessed.

| Function              | APC / Platform Role                            | External / Regulated Infrastructure                    |
| --------------------- | ---------------------------------------------- | ------------------------------------------------------ |
| Payment Orchestration | Quote · order · routing · coordination         | —                                                      |
| On-Chain Verification | Verification · confirmation · payment matching | Blockchain / RPC infrastructure                        |
| KYC / KYB             | Integration · access controls                  | Verification infrastructure where applicable           |
| KYT / AML             | Risk rules · screening · intervention          | Screening infrastructure where applicable              |
| Conversion            | Transaction / settlement coordination          | Conversion / liquidity provider                        |
| Local Acquiring       | Channel orchestration                          | PSP / acquiring provider                               |
| Fiat Clearing         | Settlement coordination                        | Bank / clearing / acquiring channel                    |
| Merchant Payout       | Payment-to-settlement coordination             | Applicable payout / banking infrastructure             |
| Card Services         | Wallet and payment integration                 | Issuer · processor · network · acquirer, as applicable |
| Insurance             | Payment and coverage integration               | Regulated insurance provider                           |
| Reconciliation        | Payment ↔ settlement record matching           | Partner settlement records                             |

A key principle is:

Technology integration does not transfer a regulated provider's legal responsibilities to APC, nor does APC's orchestration role itself establish that APC performs every regulated activity within the transaction chain.

Where APC itself performs an activity requiring authorization, the applicable requirements depend on the responsible legal entity and jurisdiction.

&#x20;

### 11.17 — Recordkeeping, Traceability & Auditability

APC's payment architecture is designed to maintain transaction-level traceability across relevant stages of payment and settlement.

<figure><img src="https://3794860345-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOKxhjRwcjf3PPe3LhOKg%2Fuploads%2FkdoF14EvUAVS9bhRLMbd%2Fimage.png?alt=media&amp;token=72fe02bc-4007-4e5b-829f-23e1c266e589" alt=""><figcaption></figcaption></figure>

Depending on applicable requirements, records may support:

&#x20;

<figure><img src="https://3794860345-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOKxhjRwcjf3PPe3LhOKg%2Fuploads%2FPzkYierXFVQrfZ8rEKi0%2Fimage.png?alt=media&amp;token=633064b5-1259-4bbc-83b9-730ec33bd600" alt=""><figcaption></figcaption></figure>

Retention requirements depend on applicable law, transaction type, jurisdiction, and participating regulated entities.

&#x20;

### 11.18 — Jurisdictional & Product Availability

APC's products are not assumed to be universally available under identical regulatory conditions.

Availability may vary according to:

* Jurisdiction
* Product
* User / Entity Type
* Digital Asset
* Blockchain Network
* Payment Channel
* Transaction Value
* Settlement Method
* Regulatory Requirements
* Partner Availability

APC may restrict, modify, suspend, or discontinue particular products, transaction routes, assets, networks, or settlement methods where required by applicable law, risk controls, regulatory requirements, or partner obligations.

&#x20;

### 11.19 — Compliance Governance & Continuous Review

Payment, digital-asset, stablecoin, card, AI, data-protection, and related regulatory frameworks continue to evolve.

APC's compliance framework is therefore intended to operate as an ongoing control environment rather than a one-time certification exercise.

<figure><img src="https://3794860345-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOKxhjRwcjf3PPe3LhOKg%2Fuploads%2Fo1w5lawWNQw4l6DlOKKR%2Fimage.png?alt=media&amp;token=6f8c8750-540a-4485-9fc2-91a1b5c9e833" alt=""><figcaption></figcaption></figure>

&#x20;Compliance controls, product availability, transaction requirements, supported jurisdictions, and partner arrangements may be updated as the regulatory and operational environment changes.

FATF's July 2026 update demonstrates why this matters: implementation of its virtual-asset standards continues to develop across jurisdictions, with remaining gaps in implementation of Recommendation 15.

&#x20;

### 11.20 — Compliance Statement

APC is committed to developing and operating payment infrastructure with compliance controls appropriate to the products, markets, transaction types, and payment channels it supports.

The framework combines customer and merchant verification, AML/CFT controls, KYT and blockchain monitoring, sanctions screening, transaction-risk controls, payment and settlement controls, partner oversight, transaction traceability, security, and jurisdiction-specific requirements.

APC does not represent that every product, digital asset, network, payment channel, or service is available or authorized in every jurisdiction.

Where regulated services are provided through external financial institutions, payment service providers, card issuers, acquirers, liquidity providers, insurers, digital-asset service providers, or other regulated entities, the applicable provider remains responsible for activities performed under its own authorization.

Compliance requirements and product availability may change as applicable laws, regulatory standards, technology, risk conditions, and partner arrangements evolve.

&#x20;

<figure><img src="https://3794860345-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOKxhjRwcjf3PPe3LhOKg%2Fuploads%2FTP0KXcMlXmRsOGHQoz6L%2Fimage.png?alt=media&amp;token=975b559e-3508-4c5a-8952-a65486fec425" alt=""><figcaption></figcaption></figure>

&#x20;&#x20;
