# Swipelux

## Docs

- [Integration overview](https://docs.swipelux.com/integration/overview.md): Build customer onboarding, fiat pay-ins, stablecoin and fiat payouts, and issued bank accounts on the Swipelux v3 API without exposing payment infrastructure.
- [Quickstart](https://docs.swipelux.com/integration/quickstart.md): Create a sandbox Swipelux customer, activate a capability, and run a pay-in, payout, or issued bank account flow end-to-end in a few backend requests.
- [Authentication](https://docs.swipelux.com/integration/authentication.md): Authenticate Swipelux API requests with the X-API-Key header from a protected backend, use separate sandbox and live keys, and keep keys out of client code.
- [Errors and retries](https://docs.swipelux.com/integration/errors.md): Handle every public Swipelux API problem code, decide when to retry, and resolve validation, state, idempotency, and platform failures.
- [Sandbox testing](https://docs.swipelux.com/integration/sandbox.md): Control capability, task, wallet, and transfer outcomes in the Swipelux sandbox environment while building and regression-testing your integration.
- [Customers](https://docs.swipelux.com/integration/onboarding/customers.md): Create the individual or business Swipelux customer that owns capabilities, wallets, bank accounts, and transfers, and attach the right onboarding profile.
- [Capabilities and tasks](https://docs.swipelux.com/integration/onboarding/capabilities-and-requirements.md): Discover, request, and activate customer capabilities for each payment flow, complete open KYC or KYB tasks, and choose between pooled and named account types.
- [Common flows](https://docs.swipelux.com/integration/common-flows.md): Pick the Swipelux integration path for receiving fiat pay-ins, sending customer payouts, or issuing a reusable bank account, all from one onboarding model.
- [Accounts and wallets](https://docs.swipelux.com/integration/accounts.md): Choose between customer-owned wallets, bank accounts, and third-party recipient destinations required by each Swipelux pay-in, payout, or issuing flow.
- [Issue a bank account](https://docs.swipelux.com/integration/issue-bank-account.md): Provision reusable IBAN or virtual account bank details for a Swipelux customer wallet and settle matched fiat deposits automatically into stablecoin balances.
- [Recipients and destinations](https://docs.swipelux.com/integration/recipients.md): Create a third-party Swipelux recipient and the bank account or crypto wallet destination that receives a payout, and reuse them across future transfers.
- [Receive funds](https://docs.swipelux.com/integration/receive-funds.md): Create a one-time Swipelux fiat pay-in transfer, present the exact bank or card funding instructions, and settle received funds into a customer wallet.
- [Send funds](https://docs.swipelux.com/integration/send-funds.md): Send a Swipelux payout from a customer wallet to a first-party bank account, another wallet, or a third-party recipient destination in fiat or stablecoin.
- [Quotes and transfers](https://docs.swipelux.com/integration/quotes-and-transfers.md): Request a Swipelux quote for an exact amount, execute one quote safely with idempotency, and track the transfer state machine through settlement.
- [Webhooks](https://docs.swipelux.com/integration/webhooks.md): Verify Swipelux Svix-signed webhook deliveries, persist unique event IDs before acknowledging, and refetch current resource state to handle retries safely.
- [Go live](https://docs.swipelux.com/integration/go-live.md): Activate a Swipelux production space, separate live from sandbox configuration, rotate keys, and launch each capability with a controlled real-money test.
- [API reference](https://docs.swipelux.com/api-reference/introduction.md): Use the Swipelux v3 API contract, authenticate with X-API-Key, retry writes safely with idempotency keys, and handle status codes and error schemas.
- [Migrate a v1 or v2 integration to Swipelux API v3](https://docs.swipelux.com/api-reference/versioning/migrate-to-v3.md): Two-pass migration guide from Swipelux API v1 and v2 to v3: object model concepts first, then endpoint mappings, state machines, and a checklist.
- [Swipelux API changelog and release notes](https://docs.swipelux.com/api-reference/versioning/changelog.md): Dated log of additions, breaking changes, and deprecations across Swipelux API versions, with upgrade notes for integrators tracking releases.
- [List related parties](https://docs.swipelux.com/api-reference/customers/get-v3-customers-by-customer-id-related-parties.md): Returns active related-party summaries for the customer with cursor pagination. Individual customers have no related parties and return an empty page. Summaries carry roles, derived display name, and ownership, voting, and control indicator booleans; archived parties are excluded.
- [Create related party](https://docs.swipelux.com/api-reference/customers/post-v3-customers-by-customer-id-related-parties.md): Creates a person or entity related party for a business customer. The party gets a stable rp_ id, requires at least one role or one ownership, voting, or control fact, and the parent customer's updatedAt advances in the same transaction.
- [Get related party](https://docs.swipelux.com/api-reference/customers/get-v3-customers-by-customer-id-related-parties-by-related-party-id.md): Returns the complete related-party resource. Absent, foreign, and archived ids all return 404 related_party_not_found.
- [Archive related party](https://docs.swipelux.com/api-reference/customers/delete-v3-customers-by-customer-id-related-parties-by-related-party-id.md): Archives the related party: the id is never reused, normal reads return 404 afterwards, and an idempotent replay returns the same 204. Deletion is blocked with 409 related_party_in_review while an active review depends on the party.
- [Update related party](https://docs.swipelux.com/api-reference/customers/patch-v3-customers-by-customer-id-related-parties-by-related-party-id.md): Deep-merges the supplied fields into the party: omitted fields stay unchanged, explicit null clears optional fields, and arrays are replaced whole. The id, customerId, and partyType are immutable.
- [List customers](https://docs.swipelux.com/api-reference/customers/get-v3-customers.md): Lists CustomerSummary resources in deterministic createdAt DESC, id DESC order. Canonical contact and free-text filters are case-insensitive and compose with exact identity and strict timestamp filters. Pass include=capabilities to attach capability summaries to every customer.
- [Create customer](https://docs.swipelux.com/api-reference/customers/post-v3-customers.md): Creates the canonical customer union atomically. Individuals require only type; businesses require business.legalName. Email and phone values are not unique customer keys.
- [Get customer](https://docs.swipelux.com/api-reference/customers/get-v3-customers-by-customer-id.md): Returns the canonical customer detail union. Business details embed active related parties.
- [Archive customer](https://docs.swipelux.com/api-reference/customers/delete-v3-customers-by-customer-id.md): Archives the customer aggregate atomically. Active accounts and in-flight transfers must be resolved first; the externalId reservation and immutable history are retained.
- [Update customer](https://docs.swipelux.com/api-reference/customers/patch-v3-customers-by-customer-id.md): Deep-merges canonical customer facts. Arrays replace atomically, null clears nullable facts, metadata merges by key, and related-party ids upsert in place.
- [Export customer data](https://docs.swipelux.com/api-reference/customers/post-v3-customers-by-customer-id-export.md): Exports a customer in the requested format. `json_basic_data` returns the public v3 customer resource as a JSON attachment with profile and related-party data only. `sumsub_share_token` creates a one-time Sumsub share token for an approved individual customer; it requires `forClientId` and an `Idemp…
- [List institutions](https://docs.swipelux.com/api-reference/institutions/get-v3-institutions.md): Lists institution IDs referenced by capability support and application resources.
- [List merchant capabilities](https://docs.swipelux.com/api-reference/capabilities/get-v3-capabilities.md): Lists capabilities across customers in the current space, ordered by `createdAt` descending.
- [Preview capability tasks](https://docs.swipelux.com/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities-by-capability-id-tasks-preview.md): Returns descriptor-only tasks from one pinned, side-effect-free evaluation snapshot.
- [List capabilities](https://docs.swipelux.com/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities.md): Lists a customer's capability requests with their current institution applications.
- [List supported capabilities](https://docs.swipelux.com/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities-supported.md): Lists every known capability variant for this customer with supported directions, availability, eligibility, and supporting institutions. `stablecoin_transfers` is always listed; `card` is omitted for business customers. For available bank-backed capability creation, omitted or empty `institutions`…
- [Get capability](https://docs.swipelux.com/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities-by-capability-id.md): Returns one v3 capability by permanent public capability id.
- [Create capability](https://docs.swipelux.com/api-reference/capabilities/post-v3-customers-by-customer-id-capabilities-by-capability-id.md): Requests a customer capability by permanent capability id. Requesting a canceled capability with a new idempotency key starts a fresh lifecycle after current eligibility and routing checks pass. For bank-backed capabilities, omitted or empty `institutions` lists select registry defaults; a non-empty…
- [Cancel capability](https://docs.swipelux.com/api-reference/capabilities/post-v3-customers-by-customer-id-capabilities-by-capability-id-cancel.md): Cancels a `pending` or `restricted` capability that has no active linked accounts or transfers. On success, tasks owned exclusively by the capability or its applications and all non-archived applications are canceled. A customer-scoped intake task shared with another active capability remains open f…
- [List capability applications](https://docs.swipelux.com/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities-by-capability-id-applications.md): Lists institution application flows for this capability. Use each application's ordered openTaskIds to fetch authorized customer task details.
- [List application history](https://docs.swipelux.com/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities-by-capability-id-applications-by-application-id-history.md): Returns canonical task history grouped by task for this institution flow.
- [List tasks](https://docs.swipelux.com/api-reference/tasks/list-tasks.md): Lists the merchant-wide task inbox with URL-free verification-session summaries.
- [List customer tasks](https://docs.swipelux.com/api-reference/tasks/list-customer-tasks.md): Lists customer-owned tasks with URL-free verification-session summaries.
- [Get a task](https://docs.swipelux.com/api-reference/tasks/get-task.md): Returns a merchant-wide task detail projection without hosted-session URLs.
- [Get customer task detail](https://docs.swipelux.com/api-reference/tasks/get-customer-task.md): Returns the authorized task action surface with its immutable allowed submission channels in canonical direct_submission then verification_session order. Process KYC sessions expose exact customer/task/session first-party action URLs only while action is required; in-review, completed or reused, rej…
- [List task history](https://docs.swipelux.com/api-reference/tasks/list-customer-task-history.md): Lists immutable task revisions without answers or hosted-session URLs.
- [Open a lifecycle KYC verification session](https://docs.swipelux.com/api-reference/tasks/start-kyc-verification-session.md): Opens one exact customer/task/session first-party link. The service validates lifecycle ownership and creates or refreshes a short-lived provider link without persisting or returning that provider URL in task JSON. Approved fake-host sandbox flows hand off to the first-party verification page. An ex…
- [List task submissions](https://docs.swipelux.com/api-reference/task-submissions/list-customer-task-submissions.md): Lists redacted submission summaries without answer values, alternatives, or document ids.
- [Create a task submission](https://docs.swipelux.com/api-reference/task-submissions/create-customer-task-submission.md): Creates one immutable direct-submission attempt for the task's current remediation round.
- [Get task submission detail](https://docs.swipelux.com/api-reference/task-submissions/get-customer-task-submission.md): Returns the authorized immutable answer snapshot and current public outcome.
- [List customer document metadata](https://docs.swipelux.com/api-reference/documents/get-v3-customers-by-customer-id-documents.md): Returns customer document metadata newest first.
- [Upload customer document](https://docs.swipelux.com/api-reference/documents/post-v3-customers-by-customer-id-documents.md): Uploads one PDF, JPEG, PNG, WebP, or HEIF/HEIC document up to 25 MB as `multipart/form-data`. Send the raw binary in the `file` part; base64 JSON is not accepted. Returns metadata for task submissions.
- [Get customer document metadata](https://docs.swipelux.com/api-reference/documents/get-v3-customers-by-customer-id-documents-by-document-id.md): Returns metadata for one customer document.
- [Archive customer document](https://docs.swipelux.com/api-reference/documents/delete-v3-customers-by-customer-id-documents-by-document-id.md): Archives one customer document. Archived documents are retained for compliance but excluded from subsequent reads, lists, and task submissions.
- [List accounts](https://docs.swipelux.com/api-reference/accounts/get-v3-customers-by-customer-id-accounts.md): Get issued and external customer accounts. The collection includes wallet accounts and bank accounts with typed details.
- [Create account](https://docs.swipelux.com/api-reference/accounts/post-v3-customers-by-customer-id-accounts.md): Create one customer account. Use `origin: "issued"` for platform-issued wallet accounts and virtual bank accounts, or `origin: "external"` for customer-owned wallet and bank accounts. Issued virtual bank accounts require `settlement.accountId`, the issued customer wallet account that receives settle…
- [Get account](https://docs.swipelux.com/api-reference/accounts/get-v3-customers-by-customer-id-accounts-by-account-id.md): Returns one customer account. Issued wallet account details include a balance collection; external wallet balance collections are empty; bank accounts include typed details when available.
- [Archive account](https://docs.swipelux.com/api-reference/accounts/delete-v3-customers-by-customer-id-accounts-by-account-id.md): Archive a customer account. Archived accounts remain available from the list endpoint when filtering with `status=archived`. Accounts referenced by in-flight transfers cannot be archived until those transfers reach a terminal state.
- [Update account](https://docs.swipelux.com/api-reference/accounts/patch-v3-customers-by-customer-id-accounts-by-account-id.md): Updates account metadata. All accounts accept `label`; issued wallets also accept `isDefault: true`; issued bank accounts also accept `settlement.accountId`.
- [Get account fees](https://docs.swipelux.com/api-reference/accounts/get-v3-customers-by-customer-id-accounts-by-account-id-fees.md): Read the developer fees configured for one customer account. This is the read-back mirror of the PUT shape; `breakdown.developer` is `null` when no rule is configured.
- [Replace account fees](https://docs.swipelux.com/api-reference/accounts/put-v3-customers-by-customer-id-accounts-by-account-id-fees.md): Replaces developer fees for one customer account. Fixed fees are major-unit decimal strings; request bodies do not carry wildcard or fee-level currency rules.
- [List recipients](https://docs.swipelux.com/api-reference/recipients/get-v3-customers-by-customer-id-recipients.md): Lists recipients for a customer.
- [Create recipient](https://docs.swipelux.com/api-reference/recipients/post-v3-customers-by-customer-id-recipients.md): Create an individual or business third-party payout recipient. First-party payouts target customer accounts.
- [Get recipient](https://docs.swipelux.com/api-reference/recipients/get-v3-customers-by-customer-id-recipients-by-recipient-id.md): Returns a recipient with its payout destinations.
- [Archive recipient](https://docs.swipelux.com/api-reference/recipients/delete-v3-customers-by-customer-id-recipients-by-recipient-id.md): Archives a recipient.
- [Update recipient](https://docs.swipelux.com/api-reference/recipients/patch-v3-customers-by-customer-id-recipients-by-recipient-id.md): Updates the supplied fields on an active recipient. Archive is terminal; archived recipients reject later updates.
- [List recipient destinations](https://docs.swipelux.com/api-reference/recipients/get-v3-customers-by-customer-id-recipients-by-recipient-id-destinations.md): Lists active recipient-owned bank and wallet payout destinations. When updatedAfter is supplied, archived transitions inside the inclusive recovery window are also returned.
- [Add recipient destination](https://docs.swipelux.com/api-reference/recipients/post-v3-customers-by-customer-id-recipients-by-recipient-id-destinations.md): Adds a bank or wallet payout destination to a recipient. Use Accounts for customer-owned destinations.
- [Get recipient destination](https://docs.swipelux.com/api-reference/recipients/get-v3-customers-by-customer-id-recipients-by-recipient-id-destinations-by-destination-id.md): Returns one recipient bank or wallet payout destination.
- [Archive recipient destination](https://docs.swipelux.com/api-reference/recipients/delete-v3-customers-by-customer-id-recipients-by-recipient-id-destinations-by-destination-id.md): Archives one recipient payout destination.
- [List rules](https://docs.swipelux.com/api-reference/rules/get-v3-customers-by-customer-id-rules.md): List the customer's standing transfer instructions with optional status and updated-after filters.
- [Create rule](https://docs.swipelux.com/api-reference/rules/post-v3-customers-by-customer-id-rules.md): Create a standing instruction: when funds become available on the trigger account, transfer them to the target. At most one non-archived rule may watch a given trigger account.
- [Get rule](https://docs.swipelux.com/api-reference/rules/get-v3-customers-by-customer-id-rules-by-rule-id.md): Archived rules stay readable for audit.
- [Archive rule](https://docs.swipelux.com/api-reference/rules/delete-v3-customers-by-customer-id-rules-by-rule-id.md): Archiving is terminal and frees the trigger account for a new rule. The archived rule stays readable.
- [Update rule](https://docs.swipelux.com/api-reference/rules/patch-v3-customers-by-customer-id-rules-by-rule-id.md): Pause or resume the rule and edit its label or metadata. Archived rules are read-only (`rule_archived`).
- [Get indicative FX rate](https://docs.swipelux.com/api-reference/money-movement/get-v3-rates.md): Returns an indicative fiat FX rate. Executable pricing is returned by quote creation.
- [Get quote](https://docs.swipelux.com/api-reference/money-movement/get-v3-quotes-by-quote-id.md): Returns a v3 quote by id. Only quotes created through `POST /v3/quotes` are exposed here.
- [List transfers](https://docs.swipelux.com/api-reference/money-movement/get-v3-transfers.md): Lists quoted transfers and reconciled inbound deposits in deterministic createdAt/id descending order. Filters are customerId, public state, method, direction, origin, source-or-destination accountId, quoteId, exact externalId, createdAt range, and updatedAfter (the missed-webhook recovery path).
- [Create transfer (executes a quote)](https://docs.swipelux.com/api-reference/money-movement/post-v3-transfers.md): Executes the selected quote without intentionally re-pricing it. Execution can still fail validation, balance, destination, rail, or provider checks.
- [Get transfer](https://docs.swipelux.com/api-reference/money-movement/get-v3-transfers-by-transfer-id.md): Returns a quoted or inbound-deposit transfer with its amounts/fees snapshot, public state, source/destination, open tasks, rail references, and instructions. Sender evidence is included when available and is never part of webhook payloads.
- [List transfer-scoped tasks](https://docs.swipelux.com/api-reference/money-movement/get-v3-transfers-by-transfer-id-tasks.md): Lists tasks scoped to this transfer in the standard page envelope. Unknown transfer ids return 404.
- [Cancel transfer](https://docs.swipelux.com/api-reference/money-movement/post-v3-transfers-by-transfer-id-cancel.md): Returns `409 transfer_not_cancelable`; no current transfer state is cancelable through this operation.
- [Get transfer instructions](https://docs.swipelux.com/api-reference/money-movement/get-v3-transfers-by-transfer-id-instructions.md): Returns the typed deposit instructions for a v3 transfer created from a quote. Payout-side transfers are funded from the source account and have no instructions: this endpoint returns a 404 problem with code `transfer_has_no_instructions` for them.
- [Create quote](https://docs.swipelux.com/api-reference/money-movement/post-v3-quotes.md): Creates a priced movement that can be executed before `expiresAt` while the quote, capability, balance, destination, rail, and provider checks still pass.
- [Credit a sandbox account](https://docs.swipelux.com/api-reference/sandbox/post-v3-sandbox-accounts-by-account-id-topup.md): Credits an issued sandbox wallet account with test funds. No real funds move.
- [Force sandbox transfer state](https://docs.swipelux.com/api-reference/sandbox/post-v3-sandbox-transfers-by-transfer-id-state.md): Forces an existing sandbox transfer to `completed` or `failed`.
- [Create sandbox task](https://docs.swipelux.com/api-reference/sandbox/post-v3-sandbox-tasks.md): Creates a canonical sandbox task scoped to a customer, capability, or transfer.
- [Review sandbox task submission](https://docs.swipelux.com/api-reference/sandbox/post-v3-sandbox-tasks-by-task-id-review.md): Accepts or rejects the current submitted sandbox task answers.
- [Simulate customer verification](https://docs.swipelux.com/api-reference/sandbox/post-v3-sandbox-customers-by-customer-id-verification.md): Approve or reject an individual KYC or business KYB review in sandbox. The environment is selected by the API key.
- [Force sandbox capability status](https://docs.swipelux.com/api-reference/sandbox/post-v3-sandbox-customers-by-customer-id-capabilities-by-capability-id-status.md): Forces a sandbox capability to `ready`, `rejected`, or `restricted`.
- [List webhook endpoints](https://docs.swipelux.com/api-reference/webhooks/get-v3-webhooks.md): Lists webhook endpoints configured for the authenticated merchant.
- [Create webhook endpoint](https://docs.swipelux.com/api-reference/webhooks/post-v3-webhooks.md): Creates a webhook endpoint with an event-type allowlist.
- [Archive webhook endpoint](https://docs.swipelux.com/api-reference/webhooks/delete-v3-webhooks-by-webhook-id.md): Archives a webhook endpoint.
- [Update webhook endpoint](https://docs.swipelux.com/api-reference/webhooks/patch-v3-webhooks-by-webhook-id.md): Updates a webhook endpoint URL or event-type allowlist.
- [Get webhook portal URL](https://docs.swipelux.com/api-reference/webhooks/get-v3-webhooks-portal.md): Returns a webhook management portal URL for delivery logs, retries, and manual replay.
- [Customer created](https://docs.swipelux.com/api-reference/webhooks/customer-created.md): Triggered after a v3 customer creation transaction and its redacted outbox event commit atomically.
- [Customer updated](https://docs.swipelux.com/api-reference/webhooks/customer-updated.md): Triggered after v3 customer facts, metadata, or related-party changes commit with a redacted change-category projection.
- [Customer archived](https://docs.swipelux.com/api-reference/webhooks/customer-archived.md): Triggered after a v3 customer and its archive cascade commit atomically.
- [Capability created](https://docs.swipelux.com/api-reference/webhooks/capability-created.md): Triggered when a canonical v3 capability is created with its task projection.
- [Capability status changed](https://docs.swipelux.com/api-reference/webhooks/capability-status-changed.md): Triggered when a canonical v3 capability enters a new public state after creation.
- [Application status changed](https://docs.swipelux.com/api-reference/webhooks/application-status-changed.md): Triggered when an institution application under a v3 capability changes state.
- [Recipient status changed](https://docs.swipelux.com/api-reference/webhooks/recipient-status-changed.md): Triggered when a v3 recipient enters a new public state.
- [Destination status changed](https://docs.swipelux.com/api-reference/webhooks/destination-status-changed.md): Triggered when a v3 recipient destination enters a new public state.
- [Account created](https://docs.swipelux.com/api-reference/webhooks/account-created.md): Triggered when a v3 wallet or bank account is created.
- [Account status changed](https://docs.swipelux.com/api-reference/webhooks/account-status-changed.md): Triggered when a v3 account status or default-account state changes.
- [Account details changed](https://docs.swipelux.com/api-reference/webhooks/account-details-changed.md): Triggered when the current routing instructions for an issued v3 bank account change.
- [Transfer state changed](https://docs.swipelux.com/api-reference/webhooks/transfer-state-changed.md): Triggered when a v3 transfer changes public state.
- [Swipelux compliance reference](https://docs.swipelux.com/knowledge-base/compliance/overview.md): Understand the Swipelux VASP compliance model, supported regions, KYC and KYB onboarding, payment methods, and the responsibility split with sub-merchants.
- [General Information](https://docs.swipelux.com/knowledge-base/compliance/regulatory-perimeter.md): Understand Swipelux's VASP regulatory role, how the crypto leg is performed by Swipelux, and where sub-merchant compliance responsibilities begin and end.
- [Supported Verticals](https://docs.swipelux.com/knowledge-base/compliance/supported-business-models.md): Swipelux classifies sub-merchant business models into allowed, conditional, and prohibited risk tiers across e-commerce, Web3, gambling, and trading.
- [Jurisdiction Framework](https://docs.swipelux.com/knowledge-base/compliance/jurisdictions-and-availability.md): Review Swipelux end-user eligibility by region, EEA and Switzerland acceptance rules, APAC and LATAM enhanced due diligence, and restricted jurisdictions.
- [Transaction Limits](https://docs.swipelux.com/knowledge-base/compliance/transaction-limits.md): Swipelux per-transaction, daily, and monthly limits by customer type and KYC verification level, and how AML risk scoring can adjust individual limits.
- [Wallet Architecture and Payouts](https://docs.swipelux.com/knowledge-base/compliance/custody-and-wallet-controls.md): Understand how Swipelux runs custodial MPC wallets for user balances and supports non-custodial payouts to verified self-custody wallets after risk screening.
- [Payment Methods](https://docs.swipelux.com/knowledge-base/compliance/payment-methods.md): Supported Swipelux pay-in and payout rails, including SEPA and Faster Payments open banking, card acquiring, crypto deposits, and third-party aggregators.
- [Travel Rule Compliance](https://docs.swipelux.com/knowledge-base/compliance/travel-rule.md): How Swipelux applies FATF Recommendation 16 Travel Rule controls to VASP-to-VASP transfers via TRISA and Notabene and to unhosted wallet withdrawals.
- [Screening and Monitoring](https://docs.swipelux.com/knowledge-base/compliance/screening-and-monitoring.md): How Swipelux performs continuous AML and CTF monitoring: sanctions and PEP screening, blockchain analytics, transaction monitoring, and case escalation.
- [Governance and Roles](https://docs.swipelux.com/knowledge-base/compliance/governance-retention-and-privacy.md): Review the Swipelux and sub-merchant liability matrix, five-year AML retention rules, GDPR data handling, and EU-hosted infrastructure boundaries.
- [Business onboarding overview](https://docs.swipelux.com/knowledge-base/business-onboarding/overview.md): Understand the Swipelux KYB policy scope, business information collected, ownership facts recorded, and evidence reviewed before a business can transact.
- [Entity and business types](https://docs.swipelux.com/knowledge-base/business-onboarding/entity-and-business-types.md): Review the entity type, industry, source-of-funds, and purpose-of-funds concepts Swipelux uses in KYB policy to classify businesses and risk-tier them.
- [Business document requirements](https://docs.swipelux.com/knowledge-base/business-onboarding/document-requirements.md): Review Swipelux KYB document categories, acceptance rules, recency windows, signature requirements, and current file size and format upload boundaries.
- [Shareholders, UBOs, and control persons](https://docs.swipelux.com/knowledge-base/business-onboarding/shareholders-ubos-and-control-persons.md): Understand Swipelux KYB ownership thresholds, distinct control-person roles, multi-tier ownership chains, related parties, and supporting evidence required.
- [KYB workflow](https://docs.swipelux.com/knowledge-base/business-onboarding/kyb-workflow.md): Follow the Swipelux business onboarding sequence: KYB review stages, enhanced due diligence triggers, expected timing, and rejection and reapplication policy.
- [Business onboarding FAQ](https://docs.swipelux.com/knowledge-base/business-onboarding/faq.md): Answers to common Swipelux KYB questions covering ownership thresholds, authority, accepted documents, upload issues, review timing, and support escalation.
- [Individual onboarding overview](https://docs.swipelux.com/knowledge-base/individual-onboarding/overview.md): Understand the Swipelux individual KYC policy scope, verification levels, information reviewed, evidence collected, and the current API implementation path.
- [KYC verification levels](https://docs.swipelux.com/knowledge-base/individual-onboarding/verification-levels.md): Review Swipelux simplified, standard, and enhanced KYC policy requirements, the triggers that move a customer between levels, and the evidence collected.
- [KYC status and workflow](https://docs.swipelux.com/knowledge-base/individual-onboarding/status-and-workflow.md): Separate Swipelux KYC review concepts from the current capability, application, task, and submission states so you can map policy status to API values.
- [Individual onboarding API workflow](https://docs.swipelux.com/knowledge-base/individual-onboarding/api-workflow.md): Map Swipelux individual KYC policy to the current Customers, Capabilities, Tasks, Task Submissions, and Documents API operations used during onboarding.

## OpenAPI Specs

- [openapi](https://docs.swipelux.com/openapi.json)