AML & CTF Policy

1. Purpose and scope

This policy sets out how WaPay identifies and manages money laundering and terrorist financing risk arising from the businesses it onboards onto its platform.

It covers merchant onboarding, due diligence, screening, ongoing monitoring, record retention and escalation. It does not cover WaPay's own corporate banking or employment arrangements.

2. Regulatory framework

3. Regulatory status and business model

WaPay is not a regulated financial institution. It does not hold, control or transmit client funds at any point.

• → Card payments are acquired by a regulated payment institution. Funds settle to the merchant's own account with that institution and are paid out by that institution to the merchant's bank.
• → Bank transfers are initiated by a regulated payment initiation service provider. Funds move directly from the payer's bank to the merchant's account. WaPay is never in the payment chain.

As an unregulated platform, WaPay is not required to appoint a board-approved Money Laundering Reporting Officer. It maintains a designated compliance lead (§4) and the controls set out below.

4. Governance

A designated compliance lead is accountable for reviewing transaction anomalies and escalations, responding to audit and information requests from payment providers, acting as the named point of contact for provider compliance teams, maintaining this policy and the merchant risk assessment, and determining whether a merchant relationship is terminated on risk grounds.

The compliance lead has authority to suspend a merchant's payment capability independently of commercial considerations.

Enquiries from payment providers, regulators and counterparties should be directed to compliance@wapay.ai, which is monitored by the compliance lead.

5. Customer due diligence

WaPay operates a third-party reliance model for merchant due diligence, as permitted under Articles 25–29 of 4AMLD. WaPay retains ultimate responsibility for the adequacy of that due diligence.

5.1 Collected at registration

Contact name and business name; email address; mobile number, monitored for deliverability; business type (sole trader or company); and trade type. Trade type is a required selection from a defined list — registration cannot complete without it. Service area may additionally be provided.

These details are self-declared and are not verified at the point of collection. Identity, ownership and bank details are verified by the regulated payment provider before any payment capability is enabled (§5.2).

The declared trade type is mapped to a merchant category code and passed to the payment provider, together with a description of the merchant's activity, so that the nature of the business is recorded and classified at the point payment capability is requested. Because the selection is mandatory and drawn from a defined list, no merchant is classified by default.

Registration alone confers no ability to request or receive payment. A platform control withholds invoicing and payment-request functionality until a payment rail is verified and active.

5.2 Verified by the regulated payment provider Operating

Before any card payment capability is enabled, the provider collects and verifies:

• ✓ The corporate entity — registered legal name; company registration number; registered address and telephone; tax identification number; company structure; and confirmation that all beneficial owners at or above the 25% threshold have been declared
• ✓ Ultimate beneficial owners (25% or more) — full name, date of birth, residential address and contact email for each ultimate beneficial owner holding 25% or more
• ✓ The representative — full name, date of birth, residential address, nationality, role and relationship to the company, contact details, and government-issued photographic identification, uploaded and verified
• ✓ The settlement account — bank account details verified before any funds are released
• ✓ Acceptance of terms — recorded with date and originating IP address

The provider screens the entity, its beneficial owners and its representative against applicable sanctions and politically-exposed-person lists, and monitors the relationship on an ongoing basis. Payment acceptance and settlement remain disabled until every requirement is satisfied. WaPay reads that status directly and does not override it.

5.3 Limitations of the reliance model

Stated explicitly because they bound what reliance can be claimed:

• · Timing. Provider verification occurs at payment setup, not at registration. A merchant may hold a registered account without having been subject to verification.
• · Coverage. Merchants who have not begun provider onboarding have not been verified. They cannot transact.
• · Rail asymmetry. The bank-transfer rail does not route through the card provider, and receives none of the verification above. See §6.
• · Evidence. WaPay receives a verification status from the provider, not the underlying due-diligence records. The extent of entitlement to that data is under review with the provider.
• · Reconciliation. WaPay receives the outcome of the provider's verification, not the verified values. Details self-declared at registration are not reconciled against them and may differ.

6. Bank transfer rail In implementation

The bank-transfer rail is not enabled for live merchants. When enabled it will operate under a stricter standard than the card rail, not a lighter one.

Payment initiation is not a separate onboarding path with reduced checks. A merchant reaches it only after completing the full due diligence in §5.2 — corporate entity, ultimate beneficial owners at or above 25%, government-issued photographic identification for the representative, and settlement account details — collected and verified by the regulated card provider under its own authorisation.

Two conditions must both hold before payment initiation is available:

• Card-provider verification complete. The provider reports the account verified and payment-enabled. WaPay reads that status and does not override it.
• A direct-debit mandate in force, executed by the merchant through the mandate provider's authenticated flow against the settlement account, and accepted by the merchant's bank.

Neither is sufficient alone. A merchant holding a mandate without provider verification cannot initiate payments; a verified merchant without a mandate cannot either.

This is enforced in code, not by procedure. A single platform control is the only route by which any document capable of collecting payment can be created, and it applies identically across every entry point — web dashboard, WhatsApp, and background jobs. Registration confers no payment capability of any kind.

6.1 Settlement account ownership

The account nominated for payment initiation is the same account the regulated card provider has verified and pays out to. As part of enabling payouts the provider verifies that the account holder name matches the verified merchant entity. Ownership is therefore established by a regulated institution under its own authorisation, and is not inferred from the account identifier.

Settlement to that account is continuing evidence of the same fact. The provider withholds payouts, or requests documentary evidence of account ownership, where it is not satisfied — so a merchant whose payouts are settling is a merchant whose account the provider has accepted and continues to accept.

A direct-debit mandate is additionally required before payment initiation is enabled. The mandate is executed by the merchant through the mandate provider's authenticated flow against that same account, and reaches an active state only where the merchant's bank accepts a debit authority against it. A mandate the bank rejects does not activate.

Status. The mandate control is implemented and has been exercised end to end against a live business account, including a successful collection against an active mandate. It is held behind a feature flag together with the payment-initiation rail itself. The rail is closed by that flag, not by an incomplete control: the check is built, tested, and will be in force from the moment the rail is opened. Reconciliation of the nominated account against the account the card provider has verified is enforced at the point the identifier is supplied, and a mismatch is rejected and audited.

7. Sanctions and PEP screening

Every merchant able to request or receive payment has been screened against sanctions and politically-exposed-person lists by the regulated payment provider, at onboarding and on an ongoing basis (§5.2). Screening is not a step a merchant can decline or defer: the provider withholds payment capability until it is satisfied, and WaPay reads that status rather than overriding it.

This holds because provider verification is a precondition of transacting, not a parallel track. A platform control (payability) withholds invoicing and payment-request functionality from any merchant the provider has not enabled. Registration alone confers nothing. As at 17 August 2026 every merchant with payment capability holds it on the provider-verified basis, and none holds it on any other basis.

The same screening reaches the payment-initiation rail. Because §6 makes card-provider verification a precondition of payment initiation rather than a parallel track, a merchant cannot reach that rail without having been screened by the provider at onboarding and monitored since. There is no path to payment initiation that bypasses it, and none that reaches it on a lighter standard than the card rail.

8. Prohibited jurisdictions Operating

WaPay does not onboard or serve merchants in prohibited jurisdictions. The list comprises:

• Jurisdictions subject to the FATF call for action — Democratic People's Republic of Korea, Iran, Myanmar.
• Jurisdictions subject to comprehensive restrictive measures — Cuba, Syria, Russia, Belarus.

Jurisdictions on the FATF list of those under increased monitoring are not prohibited. Increased monitoring calls for a risk-based response rather than refusal of service, and FATF cautions against wholesale de-risking. Merchants connected to those jurisdictions are instead flagged for enhanced due diligence under §9.

The list is reviewed by the compliance lead after each FATF plenary — ordinarily February, June and October — and on any change to applicable restrictive measures. The review, and any change to the list, are recorded.

Enforcement. Registration proceeds through a single entry point. A business making contact over WhatsApp is directed to the web registration form rather than being registered within the conversation, so there is no second path carrying different controls. Access to that form from a prohibited jurisdiction is blocked at the network edge, and the block cannot be circumvented by addressing the application directly. The form additionally offers only the markets WaPay serves.

A merchant's jurisdiction is determined from the number supplied and is never inferred by default: an unrecognised international dialling code is treated as unknown and rejected, rather than resolving to the launch market. Blocked access is recorded.

9. Risk-based approach

No fixed monetary thresholds apply. Risk is assessed on indicators rather than value. Enhanced due diligence is triggered by, at minimum: a sudden or unexplained increase in transaction volume or value; opaque or unresolvable beneficial ownership; exposure to high-risk third countries; a payment pattern inconsistent with the merchant's declared trade; or repeated failed verification attempts.

All payment and invoice activity is recorded and queryable. Automated anomaly detection and alerting is under review.

10. Record retention

Two obligations apply, with different clocks. Both take precedence over data-minimisation preferences, and over a request for erasure for the duration of the retention period.

Invoice, payment and business state-change records are retained without pruning. Retention of message-delivery evidence is being extended to meet the six-year obligation, and capture of a relationship-end date to start the five-year clock is under review.

11. Suspicious activity

Any employee who suspects that a transaction or relationship may involve the proceeds of crime or terrorist financing must report it to the compliance lead without delay, and must not disclose the suspicion to the merchant.

The compliance lead assesses each internal report, records the outcome and the reasoning whether or not it is escalated, and notifies the relevant payment provider where the activity concerns a rail they operate.

WaPay's own external reporting obligation depends on its contractual status with each provider, which is under review.

12. Training and review

The compliance lead and any employee handling merchant onboarding or payment queries receive AML/CTF training, recorded. Frequency and content are under review.

This policy is reviewed at least annually, and on any material change to the business model, payment rails, regulatory status or provider relationships.