FurlPay Docs
Open App
  • Services & Availability
  • Quickstart
  • For AI Agents
  • Monorepo
  • API Routes
  • Authenticationupdated
  • Webhook Eventsupdated
  • Error Codesupdated
  • Rate Limitsnew
  • Configuration & Setupnew
  • Merchant Paymentsnew
  • Payroll & Payoutsnew
  • Agentic Payments (x402)updated
  • Agent Trust & Mandates (TAP)updated
  • CCTP Cross-Chainupdated
  • LI.FI Swapsupdated
  • FurlPay Travels (Travel MCP)updated
  • Solana Actions & Blinks
  • Settlement Workspacenew
  • FURL Tokennew
  • Claude Connectorupdated
  • AI Assistants
  • Circlenew
  • Ramp Providersnew
  • Telegram Mini Appnew
  • Stripe Crypto
  • Persona KYC
  • Regulatory status
  • Screening & Casesnew
  • Security Postureupdated
  • Signing & WebAuthnupdated
  • Help Center
  • Getting Started
  • KYC Verification
  • Passkeys & Biometrics
  • Privacy & Data Protection
  • Transaction Statuses
  • Gasless Transfers
  • Deposits & Withdrawals
  • Managing Virtual Cards
  • Freezing & Unfreezing Cards
  • Declined Transactions
  • SDK & API Support
  • x402 Monetization Basics
  • Booking Travel
  • Travel Refunds & Cancellations

Resources

  • Changelog
  • System Status
  • OpenAPI Spec
  • Community
  • GitHub
Docs/Legal & Compliance/Screening & Cases

Legal & Compliance

Screening, monitoring and case management

This page describes the compliance controls implemented in the platform: address and name screening, transaction monitoring rules, the case queue and report exports. It describes software behaviour. It is not a statement that FurlPay holds any licence or that a given transfer is lawful.

Wallet address screening

Money routes call one address screen. It layers two checks, and the strictest result wins. Merchant payment verification adds a third:

ParameterTypeDescription
Sanctions listrequiredalwaysA bundled OFAC SDN snapshot, checked locally with no external call. A match blocks.
Circle Compliance Engineoptionalwhen configuredA second, independent opinion on Ethereum, Polygon, Arbitrum, Avalanche, OP Mainnet and Solana. Circle does not screen Base, so Base addresses get the sanctions check only.
USDC issuer blocklistoptionalUSDC routesReads the USDC contract's on-chain blocklist for the payer and the destination on the payment's network. Used when a merchant payment is verified, and by the Arc compliance checks.
  • Fail closed. Once Circle is configured, a network error, a non-2xx response or an unexpected response shape is a block. A screening outage never clears an address: payroll blocks the line and merchant verification holds the payment.
  • Review means stop. Where a route has no review queue, a review result refuses the action rather than letting it through.

Sanctions data freshness

The bundled sanctions list is a snapshot shipped with the code. It is as current as the last release that refreshed it. A deployment that needs continuously updated lists should configure an external screening provider.

Name screening for businesses

Business onboarding screens the legal name, trading name, owners and the authorised representative. The provider is chosen by COMPLIANCE_SCREENING_PROVIDER:

  • furlpay (default) — the bundled sanctions list; no external call. It does not cover politically exposed persons or adverse media.
  • complyadvantage — external sanctions, PEP and adverse-media screening; needs COMPLYADVANTAGE_API_KEY.

Each onboarding case keeps an append-only log of up to 25 screening runs and decisions. A run that never reached the provider is logged as UNAVAILABLE, never as CLEAR. Default re-screening intervals are 90 days for high and very high country risk, 180 for medium and 365 for low. These are policy defaults for a compliance team to approve, not regulatory requirements.

Transaction monitoring

Monitoring is a deterministic rule engine over an account's own ledger rows. It only reads transactions and raises alerts. It never changes a balance or holds a payment. Rules are versioned constants; changing a threshold is a reviewed code change.

ParameterTypeDescription
high_valuerequiredenabledA single transaction at or above the configured USD threshold.
velocityrequiredenabledToo many transactions, or too much value, in a rolling 24-hour window.
structuringrequiredenabledSeveral transactions just under the high-value threshold within 72 hours.
failed_anomalyrequiredenabledFive or more declined transactions within one hour.
new_wallet_exposureoptionaldisabledDeclared, not running.
geographic_riskoptionaldisabledDeclared, not running: ledger rows do not record a counterparty country.
counterparty_riskoptionaldisabledDeclared, not running: ledger rows do not record a counterparty screening result.

Disabled rules are listed with the missing data named, so the console never implies that something is monitored when it is not. Every alert has a stable key, so evaluating the same history twice opens each case once.

Case management

Reviews, screening hits and monitoring alerts become cases. Each case carries a unique source key naming one underlying event, so duplicates cannot be created. Cases are closed, never deleted.

  • Types: KYC review, KYB review, sanctions match, PEP match, adverse media, fraud, monitoring alert, travel rule, wallet screening, settlement hold.
  • Statuses: open, triaged, assigned, investigating, escalated, decision pending, resolved, closed.
  • Target response times by severity: critical 24 hours, high 72 hours, medium 7 days, low 14 days.
  • Resolutions: no action, false positive, confirmed, account restricted, reported, source resolved.

Cases are visible only to compliance officers. The subject of a case never sees it, and an officer can never act on a case about themselves. Today cases are derived automatically from business onboarding reviews and sanctions screening results.

Report exports

Officers can export CSV reports: cases, case audit trail, monitoring alerts, sanctions screening, KYB reviews and investigator activity. Columns never include dates of birth, emails, phone numbers, ID numbers or document contents, and cells are escaped against spreadsheet formula injection.

Travel rule

POST /api/compliance/travel-rule is a compute endpoint for signed-in callers. Given an amount and two counterparties, it returns the payload a transfer of that size would need. It sends nothing to any provider and does not authorise a payment. No travel-rule messaging provider is integrated: exchanging originator and beneficiary data with another institution is not implemented.

API

MethodPathDescription
POST/api/compliance/screenSigned-in: screen a name, and optionally up to 10 wallet addresses
POST/api/compliance/travel-ruleSigned-in: compute the travel-rule payload for a transfer
GET/api/compliance/jurisdictionJurisdiction rules for the caller
GET / POST/api/compliance/tierThe account's verification tier and limits
GET/api/compliance/overviewOfficers only: capability registry and health, from durable records
GET / POST/api/compliance/casesOfficers only: case queue; open a case
GET / POST/api/compliance/cases/{id}Officers only: one case; assign, escalate, decide
GET / POST/api/compliance/monitoringOfficers only: rules and alert evaluation
GET/api/compliance/reportsOfficers only: CSV exports
GET / POST/api/compliance/role-grantsRequest, approve or revoke the compliance_officer role

Setup

  • CIRCLE_COMPLIANCE_API_KEY — enables the Circle Compliance Engine layer. Unset means the sanctions list is the only address layer.
  • COMPLIANCE_SCREENING_PROVIDER and, for ComplyAdvantage, COMPLYADVANTAGE_API_KEY and COMPLYADVANTAGE_WEBHOOK_SECRET.
  • COMPLIANCE_IDENTITY_PROVIDER with the Persona or Sumsub credentials. See Persona KYC.
  • Migration 0039_compliance_cases for durable cases.

Software controls are not a compliance programme

These controls support a compliance team; they do not replace one. Whether a business may offer a service in a jurisdiction depends on licences and legal advice, which are covered in Regulatory status.
Did this page help?
Edit this page on GitHub

← Previous

Regulatory status

Next →

Security Posture