Settley KYC/AML Policy

Document owner: Compliance / Legal
Version: 0.1 draft
Effective date: [Insert date]
Review cadence: At least annually and after any material product, jurisdiction, banking, crypto, or payout-provider change
Status: Draft for partner onboarding and legal review

Implementation status: See docs/compliance/ for the engineering documentation mapping every clause below to what is actually implemented, running, or still manual. Start with docs/compliance/IMPLEMENTED_CONTROLS.md for the clause-by-clause traceability table and docs/compliance/HANDOVER_SUMMARY_FOR_CLO.md for the executive summary. This policy document has not been rewritten to match implementation status inline everywhere — treat docs/compliance/ as the source of truth for “is this actually built,” and this document as the source of truth for intended requirements.

1. Purpose

Settley provides a claim-code remittance product that allows a sender to fund an escrow with supported digital assets and allows a recipient to claim value through supported payout methods, including bank transfer, wallet transfer, airtime, data, gift card, or virtual card where available.

This KYC/AML Policy sets out Settley’s baseline controls for:

• Identifying and verifying customers and recipients.
• Preventing money laundering, terrorist financing, sanctions evasion, fraud, scams, and other prohibited activity.
• Monitoring payments, claims, and payouts.
• Escalating and reporting suspicious activity where required.
• Maintaining records for partner, audit, and regulatory review.

This policy is designed to support a risk-based compliance program. It must be reviewed by qualified counsel before production use in any regulated market.

2. Scope

This policy applies to:

• Settley employees, founders, contractors, agents, and service providers who operate or support the product.
• Senders who fund transfers.
• Recipients who claim transfers.
• Business partners, payout providers, off-ramp providers, card providers, gift-card providers, infrastructure providers, and other third parties involved in the transfer lifecycle.
• All supported chains, assets, wallets, payment methods, claim codes, and payout methods.

3. Regulatory Orientation

Settley will operate its compliance program according to generally accepted AML/CFT principles, including:

• Risk-based customer identification and verification.
• Customer due diligence and enhanced due diligence for higher-risk users or activity.
• Sanctions, politically exposed person, and adverse media screening where appropriate.
• Transaction monitoring and suspicious activity escalation.
• Recordkeeping and auditability.
• Third-party provider diligence and oversight.

Settley will also align its controls with applicable requirements in the jurisdictions where it operates, including partner-specific requirements imposed by off-ramp, card, gift-card, banking, and virtual-asset service providers.

4. Product Risk Statement

Settley involves digital assets, cross-border transfers, claim codes, and third-party payout rails. These features create specific financial crime risks, including:

• Use of stolen or sanctioned funds to fund escrow.
• Use of claim codes to obscure the relationship between sender and recipient.
• Structuring transfers to avoid limits or review.
• Fraud, romance scams, mule activity, account takeover, or coercion.
• Sanctions evasion through wallet transfers or indirect beneficiaries.
• Abuse of gift cards, airtime, or virtual cards for resale or laundering.
• Mismatch between stated transfer purpose and actual behavior.
• Payout to false identities, compromised accounts, or unauthorized recipients.

Settley will mitigate these risks through identity controls, transfer limits, wallet screening, payout provider controls, monitoring rules, manual review, and audit records.

5. Roles and Responsibilities

5.1 Founder / Executive Management

Executive management is responsible for:

• Approving this policy and material changes.
• Ensuring adequate resources for compliance operations.
• Setting risk appetite, transfer limits, and supported corridors.
• Suspending product features or markets when compliance risk is unacceptable.

5.2 Head of Legal / Compliance Lead

The Head of Legal or designated Compliance Lead is responsible for:

• Maintaining this policy.
• Reviewing partner requirements and regulatory obligations.
• Approving KYC/KYB standards and escalation procedures.
• Reviewing high-risk cases and suspicious activity escalations.
• Coordinating with outside counsel and regulated partners.
• Ensuring recordkeeping, audit readiness, and staff training.

5.3 Operations and Product Team

Operations and Product are responsible for:

• Implementing this policy in workflows, product screens, APIs, and back-office tooling.
• Ensuring payout status is based on provider confirmation, not user assertion.
• Ensuring claim and payout records are durable, auditable, and protected.
• Maintaining controls against duplicate payouts and unauthorized claims.

6. Customer Identification and Verification

Settley will apply a tiered, risk-based KYC model. The minimum required information depends on the role, value, jurisdiction, payout method, and partner requirements.

6.1 Sender Information

For senders, Settley may collect:

• Full name.
• Email address and/or Telegram handle.
• Phone number.
• Wallet address.
• Country of residence.
• Date of birth where required.
• Government identification where required.
• Source of funds or purpose of transfer where required.
• Device, IP, and session metadata.

For lower-risk, low-value transfers, Settley may apply simplified due diligence if permitted by applicable law and partner requirements. Higher-risk activity requires enhanced due diligence.

Implemented: identity collection above KYC_THRESHOLD_USD (src/compliance.ts), with government ID capture and OCR-based name/DOB/ID-number matching (src/compliance-document.ts, OCR via Tesseract or Qwen). See docs/compliance/IMPLEMENTED_CONTROLS.md §1–2.

6.2 Recipient Information

For recipients, Settley may collect:

• Full name.
• Email address, Telegram handle, and/or phone number.
• Country of residence.
• Payout method selected.
• Bank name and account number for bank payout.
• Wallet address for wallet payout.
• Cardholder information for virtual card issuance.
• Gift-card or airtime delivery information.
• Government identification, BVN, NIN, or other local identity fields where required by provider or law.

Settley will not promise bank, OPay, card, or gift-card payout unless the relevant provider confirms the payout method is supported and the recipient passes required checks.

6.3 Business Customers and Partners

For business customers, partners, and vendors, Settley may collect:

• Legal entity name.
• Registration number.
• Registered address.
• Tax identification number where applicable.
• Beneficial ownership information.
• Director or controller information.
• Proof of authorization.
• Business activity and expected volumes.
• Licenses or regulatory registrations where applicable.
• Sanctions, PEP, adverse media, and watchlist screening results.

7. Sanctions and Watchlist Screening

Settley will screen, directly or through vendors and partners where applicable:

• Senders.
• Recipients.
• Business customers.
• Beneficial owners and controllers.
• Wallet addresses.
• Payout accounts.
• High-risk counterparties.

Screening may include sanctions lists, PEP lists, adverse media, law enforcement lists, blockchain risk scores, and provider-specific watchlists.

Settley will not process a transfer, claim, or payout where it knows or has reason to believe that a party is sanctioned, blocked, prohibited, or otherwise ineligible.

Implemented: person screening via OpenSanctions (src/opensanctions.ts, screenPersonWithOpenSanctions). Wallet-address screening also now implemented (see §8 below) — added after this policy’s v0.1 draft, not yet reflected in the version number. See docs/compliance/IMPLEMENTED_CONTROLS.md §3–4. Not implemented: PEP-specific list beyond whatever OpenSanctions’ generic topics surface; business/beneficial-owner screening (§6.3) is not built.

8. Wallet and Blockchain Risk Controls

For on-chain deposits and wallet payouts, Settley will apply controls appropriate to the asset, chain, value, and jurisdiction, which may include:

• Screening sender and recipient wallet addresses.
• Detecting exposure to sanctioned addresses, mixers, darknet markets, scams, stolen funds, ransomware, or high-risk services.
• Requiring additional review for indirect high-risk exposure.
• Rejecting or holding transfers linked to prohibited activity.
• Preserving transaction hashes, chain IDs, token addresses, timestamps, and confirmation records.

Supported chains and tokens must be approved before production support. New chains or assets require a compliance and operational review.

Implemented: the funding wallet address is screened against OpenSanctions’ CryptoWallet dataset (screenWalletWithOpenSanctions in src/opensanctions.ts), scoped to transfers the sender funded directly on-chain — not fiat-onramp-funded transfers, since there is no sender-controlled address to screen there. This is risk-based, not per-transaction: a wallet is screened once per customer the first time it funds a payment, and the verdict is cached (verified_wallets table) rather than re-queried on every transfer. See docs/compliance/RISK_MODEL.md for the reasoning and docs/compliance/IMPLEMENTED_CONTROLS.md §4 for the trigger/behaviour detail. Not implemented: general blockchain risk scoring (mixer/darknet/high-risk-exchange exposure) — only direct sanctions-list address hits are caught; see docs/compliance/THIRD_PARTY_PROVIDER_MODEL.md for what a broader control would require.

9. Risk Rating

Settley will assign risk ratings to users, transfers, claims, and payouts. Risk factors may include:

• Country of sender or recipient.
• Transfer amount and frequency.
• Payout method.
• Chain and asset used.
• Wallet risk score.
• Use of privacy tools, mixers, bridges, or high-risk exchanges.
• Inconsistent identity or account information.
• Multiple claims to the same payout account.
• Multiple accounts controlled by the same device, IP, phone number, wallet, or beneficiary.
• Scam indicators or user reports.
• Provider alerts, failed checks, or manual review outcomes.

Risk ratings may be low, medium, high, or prohibited. High-risk activity requires enhanced review before payout.

10. Enhanced Due Diligence

Enhanced due diligence may be required when:

• Transfer value exceeds internal or provider thresholds.
• Activity is unusual for the user’s profile.
• User, wallet, corridor, or payout method is high risk.
• Recipient requests a high-risk payout method.
• There is adverse media, sanctions proximity, PEP exposure, or law enforcement concern.
• A partner or provider requests additional information.

Enhanced due diligence may include:

• Government ID verification.
• Selfie or liveness verification.
• Proof of address.
• Source of funds or source of wealth.
• Relationship between sender and recipient.
• Purpose of transfer.
• Additional wallet or transaction history review.
• Manual compliance approval.

11. Transfer and Payout Limits

Settley will maintain configurable transfer limits by:

• User verification tier.
• Country.
• Chain and token.
• Payout method.
• Provider limit.
• Daily, weekly, monthly, and lifetime volume.
• Risk score.

Initial production limits should be conservative until provider reliability, fraud controls, and compliance workflows are validated.

Suggested draft limits for legal review:

These draft limits are placeholders and must be confirmed by legal counsel and payout providers.

12. Transaction Monitoring

Settley will monitor the full transfer lifecycle:

1. Payment intent created.
2. Stablecoin deposit detected.
3. Deposit verified.
4. Claim code issued.
5. Recipient claim initiated.
6. Payout method selected.
7. Recipient and payout details validated.
8. Payout created with provider.
9. Provider webhook confirms success, failure, or reversal.

Monitoring rules may include:

• Multiple failed claim attempts.
• Repeated transfers below review thresholds.
• Rapid claim-and-payout behavior.
• Multiple recipients using the same payout account.
• Multiple senders funding one recipient.
• Multiple recipients linked to one wallet, IP, device, email, or phone.
• Wallet exposure to high-risk services.
• Attempts to claim from sanctioned or unsupported jurisdictions.
• Gift-card or virtual-card abuse patterns.
• Mismatches between sender instructions and recipient details.

Alerts will be reviewed by the Compliance Lead or designated operations staff.

Implemented: a rules engine (src/transaction-monitoring.ts) covering structuring (repeated sub-threshold transfers), shared payout accounts across distinct senders, and claim-velocity bursts, writing alerts to transaction_monitoring_alerts reviewable via GET/POST /api/admin/alerts. Not yet operational: nothing currently schedules this engine to run automatically — it exists as a callable module, not a live watcher. See docs/compliance/IMPLEMENTED_CONTROLS.md §5 and docs/compliance/OPERATING_PROCEDURES.md §3. Not implemented: the remaining monitoring rules this section lists (wallet mixer/bridge exposure, gift-card/virtual-card abuse patterns — gift card and virtual card are not implemented payout methods in this codebase at all today) and no SAR filing/reporting mechanism — see docs/compliance/SAR_ESCALATION_WORKFLOW.md.

13. Claim Code Controls

Claim codes are sensitive financial instruments. Settley will:

• Generate unique, high-entropy claim codes.
• Store claim codes securely.
• Associate each claim code with one funded payment intent.
• Prevent reuse after successful payout.
• Expire unclaimed codes after a defined period.
• Allow sender cancellation or refund where permitted and safe.
• Lock claim codes after excessive failed attempts.
• Require additional verification when claim behavior is suspicious.

Claim codes must not be considered paid until the payout provider confirms successful delivery or settlement.

14. Payout Provider Controls

Settley may use third-party providers for bank payout, off-ramp, gift cards, airtime, data, virtual cards, or wallet infrastructure.

Before production use, each provider must be reviewed for:

• Supported countries and payout methods.
• Licensing, regulatory posture, and terms of service.
• KYB and KYC requirements.
• Sanctions and AML controls.
• Data protection and privacy practices.
• Fees, limits, and settlement timelines.
• API reliability and incident process.
• Webhook signing and status reconciliation.
• Refund, reversal, dispute, and failed payout handling.

Provider integrations must use:

• Unique idempotency keys.
• Internal payout references.
• Provider payout references.
• Webhook signature verification where available.
• Status reconciliation and retry logic.
• Manual review for ambiguous or delayed payout states.

15. Prohibited Activity

Settley prohibits use of the product for:

• Money laundering or terrorist financing.
• Sanctions evasion.
• Fraud, scams, extortion, blackmail, ransomware, or stolen funds.
• Human trafficking, child exploitation, or illegal goods and services.
• Illegal gambling or unlicensed financial activity.
• Structuring or evasion of limits.
• Use by sanctioned persons or persons in prohibited jurisdictions.
• Use of another person’s identity or payout account without authorization.
• Resale or abuse of gift cards, cards, or airtime in violation of provider rules.

Settley may suspend, reject, hold, refund, or report activity that appears prohibited or suspicious.

16. Suspicious Activity Escalation

When activity is suspicious, Settley will:

1. Pause the transfer, claim, or payout where operationally possible.
2. Preserve all relevant records.
3. Conduct internal review.
4. Request additional information where appropriate.
5. Escalate to the Head of Legal or Compliance Lead.
6. Notify or report to regulated partners or authorities where legally required.
7. Avoid tipping off users where prohibited.

Suspicious activity decisions and rationale must be documented.

17. Recordkeeping

Settley will maintain records of:

• Customer and recipient identity information.
• KYC/KYB checks and verification results.
• Sanctions, PEP, adverse media, and wallet screening results.
• Payment intents, deposits, claims, payouts, refunds, reversals, and failures.
• On-chain transaction hashes and confirmations.
• Provider references and webhook payloads.
• Manual reviews and escalation decisions.
• Policy versions and approvals.
• Staff training records.

Records should be retained for at least five years unless a longer period is required by law, partner agreement, or internal policy.

Implementation note: compliance profiles, wallet-screening cache entries, monitoring alerts, claims, and the admin action audit log are retained indefinitely today (no deletion job exists), which satisfies this floor. The uploaded ID document image specifically defaults to 30-day retention (COMPLIANCE_DOCUMENT_RETENTION_DAYS), which does not match this five-year statement, and that expiry is not currently enforced by any running job — see docs/compliance/RETENTION_POLICY.md for the full breakdown and resolution options. This is a live discrepancy this policy should be updated to resolve, not a settled fact.

18. Data Protection

Settley will collect only the information reasonably required for product operation, compliance, fraud prevention, and partner obligations.

Sensitive data must be:

• Stored securely.
• Access-controlled.
• Encrypted where appropriate.
• Shared only with providers, partners, and authorities where necessary and permitted.
• Retained according to legal and operational requirements.
• Deleted or anonymized when retention is no longer required.

19. Training

Settley personnel involved in product, operations, support, engineering, compliance, or partner management must receive AML/KYC training appropriate to their role.

Training should cover:

• Product-specific financial crime risks.
• Red flags and escalation procedures.
• Sanctions and prohibited activity.
• Data handling.
• Claim-code and payout controls.
• Incident and suspicious activity handling.

20. Independent Review

Settley will periodically review the effectiveness of this policy and related controls. Reviews may be conducted internally or by external counsel, auditors, or compliance consultants.

Reviews should consider:

• Changes in product functionality.
• New payout providers or corridors.
• Regulatory changes.
• Fraud or suspicious activity trends.
• Partner feedback.
• Incident reports.
• Monitoring rule performance.

21. Current Implementation Gaps to Resolve Before Production

Before Settley launches live fiat, card, or gift-card payouts, the following must be completed:

• Durable database for payments, claims, recipients, payouts, and audit logs. Done — Supabase, see docs/compliance/README.md module map.
• KYC/KYB vendor or provider-led KYC flow. Partially done — self-built OCR + OpenSanctions screening (docs/compliance/IMPLEMENTED_CONTROLS.md §1–3), not a dedicated KYC vendor integration. No KYB (business customer) flow exists at all.
• Wallet screening provider or documented manual wallet review process. Done (as of this work) — see docs/compliance/IMPLEMENTED_CONTROLS.md §4. Scoped to direct sanctions-list hits, not general blockchain risk scoring.
• Provider-specific payout integration and signed webhook handling. Done for the live partners (Turnkey, MoonPay, Coinbase fail closed on missing secrets; Switch is a documented exception with no signing mechanism) — see CLAUDE.md webhook-verification rules. Not otherwise re-documented here.
• Idempotent payout creation and retry controls. Done — confirmPayout() skeleton (src/payout.ts) and atomic compare-and-swap claim locking (lockClaimForPayout); see CLAUDE.md Customer Funds Safety Rules.
• Clear refund and failed-payout process. Done — see src/recovery.ts and CLAUDE.md’s atomic-refund-lock rules.
• Transfer limits approved by legal and providers. Still draft — §11’s tiers are placeholders pending legal/provider confirmation.
• Terms of service, privacy policy, and user disclosures. Status not verified as part of this engineering review — check with legal directly rather than assuming from this document.
• Jurisdiction and licensing review. Not done — separate from and larger than this compliance module; includes state money-transmitter licensing, not just federal MSB registration. See docs/compliance/HANDOVER_SUMMARY_FOR_CLO.md.
• Incident response process. Partially done — this repo has a strong post-mortem practice (CLAUDE.md’s incident log) but no formal, pre-defined incident response plan (roles, notification timelines, regulatory-reporting triggers) exists as a document.
• Transaction monitoring. New item, partially done — rules engine exists and is tested but not scheduled to run automatically; see docs/compliance/IMPLEMENTED_CONTROLS.md §5.
• SAR/escalation workflow. New item, not done — alert/hold generation only; no case management, no filing mechanism. See docs/compliance/SAR_ESCALATION_WORKFLOW.md.

22. Approval

By signing below, the undersigned acknowledge that they have reviewed this KYC/AML Policy and approve it for use as Settley’s baseline compliance policy, subject to legal review and updates required by applicable law, provider requirements, and product changes.

Head of Legal

Name: ________________________________________________

Title: Head of Legal

Signature: ___________________________________________

Date: ________________________________________________

Founder

Name: Naro Omo-Osagie

Title: Founder

Signature: ___________________________________________

Date: ________________________________________________

Founder

Name: Temisan Gerrrard Agbajoh

Title: Founder

Signature: ___________________________________________

Date: ________________________________________________