Skip to main content

Bridge — Customers & Compliance

What this covers / who it's for. A durable, dated digest of Bridge's platform/customers/* docs (onboarding + KYC/KYB compliance) so nobody re-researches it from scratch. Facts reflect apidocs.bridge.xyz as fetched on 2026-09-03; the bridge-development skill's protocol (llms.txt → matching .md page) is how to re-verify a claim. Before trusting a number here, check changelog/changelog.md — nothing here is live in Stables code yet: BridgeRailsProvider (D118) is registered but not granted, no mirror handlers exist for Bridge customer objects. "Implications for Stables" per section notes what applies once (or if) onboarding routes to Bridge.

1. Page index​

All URLs are apidocs.bridge.xyz paths, fetched 2026-09-03.

PageURLCovers
Overviewplatform/customers/overview.mdCustomers API vs KYC Links, ToS-only path, endorsements gate
Customers APIplatform/customers/customers/api.mdAPI payloads, kyc_status lifecycle, rejection shape, government-ID table
KYC linksplatform/customers/customers/kyclinks.mdHosted (Persona) flow, status transitions, iframe embedding
Additional requirementsplatform/customers/customers/add_req.mdRe-KYC links, restricted-US-customer limits
Endorsementsplatform/customers/customers/endorsements.mdEndorsement types, requirements/future_requirements shape
Terms of serviceplatform/customers/customers/tos.mdToS link flow, signed_agreement_id, v1 vs v2
Rejection reasonsplatform/customers/customers/rejection_reasons.mddeveloper_reason → reason mapping (~48 rows)
Missing requirements and issuesplatform/customers/customers/missing-requirements-and-issues.mdEvery missing/issues machine code
BRL Ramp Migration Guideplatform/customers/customers/brl-ramp-migration-guide.mdpix_onramp/pix_offramp split (2026-06-15)
Postal code validationplatform/customers/customers/postal-code-validation.mdPer-country postal regex for the cards endorsement
EEA updated requirementsplatform/customers/customers/eea-updated-requirements.mdMiCA/EMI-CASP EEA field changes (2026-06-15/26)
SEPA/Euro transactionsplatform/customers/customers/sepa-euro-transactions.mdSEPA prerequisites, excluded regions, "Bridge EEA+" list
Individualsplatform/customers/compliance/individuals.mdStandard vs enhanced data, restricted-customer limits, ID types by country
Businessesplatform/customers/compliance/businesses/overview.mdStandard vs enhanced KYB data, UBO/control-person definitions
Business entity typesplatform/customers/compliance/businesses/entity.mdEntity types Bridge recognizes
Business ownership documentsplatform/customers/compliance/businesses/ownership.md25% UBO rule, control-person attestation, acceptable docs
Business formation documentsplatform/customers/compliance/businesses/formation.mdAcceptable formation docs per entity type
Business identification numbersplatform/customers/compliance/businesses/identification.mdBusiness ID type values by country (~180 rows)
High risk business activitiesplatform/customers/compliance/businesses/highrisk.mdDisclosure list + ToS-prohibited activities list
DAOsplatform/customers/compliance/dao.mdDAO core vs enhanced KYB, manager KYC
Supported documentsplatform/customers/compliance/docs.md31 document purposes enum values
Proof of address requirementsplatform/customers/compliance/poa.mdPoA triggers, accepted docs, 90-day/no-PO-box rules
Supported Countries Listplatform/customers/compliance/supported-countries-list.md251-row risk-tier × rail-support table
Business industry codesplatform/customers/compliance/business-industry-list-updated-2022-naics-codes.mdValid business_industry = NAICS 2022 codes (~1,000 rows)

Bridge offers two onboarding channels, chosen per integration, not per customer:

  • Customers API — the integrator builds its own UI and POSTs the full KYC payload to POST /v0/customers (Idempotency-Key + Api-Key headers), then handles remediation via PUT /v0/customers/{id} (partial bodies, same shape as create). (platform/customers/customers/api.md)
  • KYC Links — a hosted flow backed by Persona: POST /v0/kyc_links with only full_name, email, type (individual|business), optional redirect_uri, optional endorsements: ["sepa"]/endorsement: "base". Returns id, kyc_link, tos_link, kyc_status, tos_status, later customer_id; poll GET /v0/kyc_links/{id}. iframe embedding replaces /verify with /widget and passes iframe-origin=encodeURIComponent(window.location.origin) + allow="camera;". (platform/customers/customers/kyclinks.md)

The KYC link's own kyc_status enum (not_started, under_review, incomplete, awaiting_questionnaire, awaiting_ubo, approved, rejected, paused, offboarded) is distinct from the resulting customer object's status/kyc_status (§5) — two separate provider-side fields, not one.

What Bridge does: identity/database checks, sanctions screening, document verification, manual review where required, endorsement grants. What the integrator does: collect+submit the full payload (API path) or distribute the hosted link and poll/webhook the customer object (KYC Links path). Timing: automated decision typically < 1 minute; manual review → next business day; KYB same-to-next business day. (platform/customers/customers/api.md)

Implications for Stables:

  • A provider_customers-style mapping (see the conduit-mirror-domains onboarding module pattern) must store the Bridge customer_id and, for the hosted path, the kyc_link.id separately — not interchangeable.
  • D117's activity declaration runs before either Bridge channel is invoked — a Stables-owned gate, not something Bridge replaces.
  • Channel choice (API vs hosted) is undecided for the D118 Bridge adapter's onboarding capability group.

3. Terms of Service acceptance ordering​

ToS acceptance is a precondition for Bridge processing any KYC/KYB submission. Two ToS versions exist: v1 (USD/base rails) and v2 (launched 2024-04-14, required for SEPA/EUR).

  • New customer: POST /v0/customers/tos_links (Idempotency-Key) → {url} pointing at dashboard.bridge.xyz/accept-terms-of-service?session_token=…. With redirect_uri, the app receives signed_agreement_id as a query param; in an iframe/WebView, listen for a postMessage carrying signedAgreementId. signed_agreement_id is then passed into POST /v0/customers.
  • Existing customer / new version: GET /v0/customers/{id}/tos_acceptance_link → {url}, same redirect/postMessage mechanics.
  • KYC Links path: ToS is the tos_link field returned alongside the KYC link; tos_status flips pending → approved. ToS-only without KYC is explicitly supported — "legal acceptance now, onboarding later" (platform/customers/overview.md). Link expiry is not stated — silent (§12). (platform/customers/customers/tos.md)

Implications for Stables: signed_agreement_id + accepted ToS version must be persisted per customer; a "re-accept ToS" action is needed whenever requirements.missing names terms_of_service_v1/_v2 (§6). ToS acceptance sits ahead of, not instead of, the D117 gate — it's Bridge's own precondition, separate from Stables' pre-KYB business-model screen.

4. Business/KYB onboarding: associated persons + UBO rules (incl. EEA 2026-06)​

Business payload (type: business) carries business_legal_name, business_type (entity types: sole proprietorship, GP/LP/LLP, corporation, LLC, trust, cooperative, nonprofit, foundation, DAO), business_industry (NAICS 2022 code as a string), is_dao, is_high_risk, high_risk_activities[], conducts_money_services, conducts_money_services_using_bridge, compliance_screening_explanation, operates_in_prohibited_countries, account_purpose, source_of_funds, ownership_threshold, has_foreign_tax_registration, identifying_information[] (ein USA; cnpj BRA, rfc MEX, crn|vat GBR, siren|siret FRA), documents[], signed_agreement_id. (platform/customers/customers/api.md)

Associated persons — Bridge's docs are internally inconsistent on the field name (§7): the api.md create-time example uses ultimate_beneficial_owners[], but every other page (ownership, missing-requirements, EEA, BRL) uses associated_persons[], and there is a dedicated sub-resource POST|PUT|GET|DELETE /v0/customers/{customerID}/associated_persons/{id}. Person fields: first_name, last_name, birth_date, email, phone, residential_address{}, identifying_information[], documents[], has_ownership, ownership_percentage, has_control, is_director, is_signer, title, relationship_established_at, attested_ownership_structure_at.

UBO rule: every individual owning ≥25% must be identified; identities must be attested by a control person (has_control: true + attested_ownership_structure_at timestamp) or substantiated by an ownership document (documents[].purposes: ["ownership_information"]). The hosted flow reduces this to a checkbox. Missing codes: control_person, ownership_structure_attestation, business_ownership_document, business_formation_document. (platform/customers/compliance/businesses/ownership.md)

EEA changes, effective 2026-06-15 for new customers / 2026-06-26 for existing customers (platform/customers/customers/eea-updated-requirements.md), scoped to individuals whose residential address is in the EEA or businesses incorporated in the EEA (physical operating address alone no longer puts a business in scope, per the page's own June-2026 changelog note):

  • Ownership document required regardless of attestation for in-scope businesses; full KYC on all UBOs, ≥1 director (was ≤2), and all signers; is_director now mandatory on every associated person; a Letter of Authority (proof_of_signatory_authority) is required for signers who are neither director, owner, nor control person.
  • Individuals: place_of_birth{country, city} (country required, city recommended ahead of a 2027 EU-law requirement), nationalities[] (deprecates single-value nationality, both honored during migration), account_purpose now required for all EEA individuals (was high-risk only), both a national ID and a TIN — ownership-% per UBO is now required only for high-risk businesses.
  • TIN issuing-country match + tax-residency disclosure due 2026-12-31, scoped (per the page's own June-2026 note) to Bridge custodial wallet customers only. Expired government photo IDs now cause loss of endorsement access.

Documents: the canonical purposes enum lives on the Supported documents page (31 values, including business_formation, ownership_information, ownership_chart, proof_of_address, evidence_of_good_standing, proof_of_signatory_authority, regulatory_license_registration); the api.md example payload uses non-canonical purpose strings (statement_of_funds, ownership_document, proof_of_address_document, formation_document) — treat the enum page and the missing-requirements page as authoritative, not the example (§7).

Status: every business submission goes through manual review (under_review); awaiting_ubo while any listed UBO's own application is incomplete. Enhanced KYB (source of funds, revenue, high-risk disclosures, geographies, money-transmission disclosure) is required to exceed the caps in §10.

Implications for Stables: business + N associated persons need modeling as separate provider objects with their own IDs/KYC states plus role flags (has_ownership, has_control, is_director, is_signer) and an attestation timestamp — a UBO is not a business sub-field. The EEA field set is a compliance-module concern (app-modules/compliance/README.md) distinct from D117 — D117 gates whether KYB proceeds, EEA fields are what data it collects, EEA-scoped only. Document store should key on Bridge's canonical purpose enum, not the API example's strings. NAICS picker: Stables\Bridge\Lists\IndustryCodes in bridge-sdk already tracks this list — reuse it.

5. Customer status lifecycle (non-linear)​

The customer object carries status (aka kyc_status) plus a per-endorsement status; Bridge recommends gating access on both together, not status alone. (platform/customers/customers/api.md)

Values observed across pages: not_started, incomplete, awaiting_ubo, under_review, active (the api.md term) / approved (the KYC-link and endorsement term — terminology drifts between pages, §7), rejected, deposits_restricted, paused, offboarded, plus awaiting_questionnaire on KYC links specifically.

Documented transitions: not_started -> incomplete; not_started -> awaiting_ubo; not_started -> active; not_started -> under_review -> active|rejected; not_started -> rejected. deposits_restricted, paused, and offboarded are reachable from any state — a non-linear state machine, not a pipeline. deposits_restricted auto-returns new incoming deposits but still allows withdrawals; offboarded is permanent. requirements_due[] on the customer object lists outstanding items (e.g. id_verification, external_account).

Rejection is NOT permanent. rejection_reasons[]{developer_reason, reason, created_at} is an append-only array; PUT any subset of fields at any time and the customer continues through KYC — the BRL page repeats "no permanent denial" explicitly. developer_reason is internal-only (may contain sensitive detail), never shown to an end user; reason is the customer-safe string. The rejection-reasons page maps ~48 developer_reason → reason pairs (e.g. "Unsupported country" → "Your region is not supported"). (platform/customers/customers/rejection_reasons.md)

Webhooks referenced (BRL migration page): customer.updated, customer.updated.status_transitioned, kyc_link.updated.status_transitioned, virtual_account.created — distinguishing a status transition from a generic update requires inspecting the endorsement-status sub-object in the payload, not just the event name.

Implications for Stables: a Bridge customer mirror needs a state machine tolerating jumps to deposits_restricted/paused/offboarded from any prior state — not the linear pending → approved → active shape other vendor integrations use. developer_reason must route through the app's redaction/DLP path (never logged raw or shown to a tenant). Resubmission ("fix and retry") is required — rejection is not a dead end. The active/approved drift (§7) means a mirror's internal status enum should translate, not copy Bridge's field values verbatim.

6. Endorsements per rail + requirements/issues machine codes​

An endorsement is Bridge's per-rail eligibility gate — a customer transacts on a rail only once the matching endorsement is approved. Types: base (USD rails), sepa (EUR), spei (MXN), pix (BRL — being split into pix_onramp [BR residents only] and pix_offramp [all], effective 2026-06-15, with pix itself deprecated 2026-07-01), faster_payments (GBP), cop (COP via Bre-B/bank). A cards endorsement is referenced only from the postal-code-validation page — it is not defined on the endorsements page itself (§7). (platform/customers/customers/endorsements.md)

Shape: {name, status: incomplete|approved, requirements: {complete[], pending[], missing: {all_of[]} | null, issues[]}, future_requirements?: {effective_date, pending, missing, issues}}. A legacy shape additional_requirements[] (e.g. kyc_with_proof_of_address, tos_v2_acceptance) also appears on the SEPA-specific page.

Prerequisites: the ToS version that endorsement needs (base → v1, sepa → v2), plus for sepa specifically, possibly proof of address (§8). SEPA is unavailable for CAF, EGY, KWT, TUN. Cross-endorsement dependency codes has_base/has_sepa appear in missing. Requested either at KYC-link creation (endorsements[]/endorsement) or later via GET /customers/{id}/kyc_link?endorsement=sepa — no standalone "add endorsement via the Customers API" endpoint appears on this page set, though the BRL page's phrasing implies one exists in the API reference (§12). future_requirements is an endorsement approved today that will block on an effective_date — Bridge expects the integrator to monitor and prompt ahead of time.

Requirements/issues machine codes (platform/customers/customers/missing-requirements-and-issues.md): missing codes map 1:1 to payload fields (address_of_incorporation, business_formation_document, control_person, has_valid_national_id, id_not_expired, nationalities, ownership_structure_attestation, terms_of_service_v1/_v2, etc.). issues families: age (customer_too_young, customer_over_age), compatibility (endorsement_not_available_in_customers_region), document/PoA (poa_invalid_document_type, poa_manipulated, poa_name_mismatch, poa_past_90_days, poa_virtual_or_po_box), risk flags (high_risk_business_activities, operates_in_prohibited_countries, suspicious_source_of_funds), database checks (business_ein_no_match, database_check_failed_on_<field>), terminal declines (rejected_due_to_unsupported_geo, rejected_due_to_unsupported_business_activities). The BRL page adds pix-specific codes marked "still being finalized" (selfie_missing, control_persons_missing) — treat as unstable.

Implications for Stables: endorsements need modeling as a child collection per customer (name, status, a requirements snapshot, future_requirements + effective_date) — not a flag on the customer row, since several endorsements can be in different states at once. Product actions (e.g. "send a EUR payout") should route to the specific endorsement they need, not a generic "customer is KYC'd" check — the mechanism a future Bridge-routed onboarding capability (D118) would need to expose alongside D117's activity-to-provider matrix. Build a code → (field, actor, remediation, user-safe copy) registry for missing/issues codes; treat unknown codes as "needs manual review," never a silent pass. Schedule reminders ahead of any future_requirements.effective_date.

7. Bridge doc inconsistencies noticed​

  • Restricted-US-customer cap window: individuals.md says "$100,000 lifetime"; add_req.md and dao.md both say "$100,000 over a 30-day period." Per-transaction figure ($10,000) agrees across all three. Treat 30-day as more likely (2 of 3 sources, matches the DAO cap pattern) but do not build a hard rule without confirming with Bridge (§12).
  • UBO array field name: api.md's create example uses ultimate_beneficial_owners[]; every other page and the dedicated sub-resource use associated_persons[] — treat the latter as authoritative (it matches the sub-resource CRUD endpoint).
  • Document purposes values: api.md's example uses statement_of_funds/ownership_ document/proof_of_address_document/formation_document, none of which appear in the canonical 31-value enum on .../compliance/docs.md (which has proof_of_source_of_funds, ownership_information, proof_of_address, business_formation instead). Treat the enum page as authoritative.
  • Customer terminal-success status name: api.md uses active; KYC-links and endorsements pages use approved for the same concept. No page reconciles this.

8. Region-specific ID / document requirements​

  • Individuals (platform/customers/compliance/individuals.md): ~160-country table of identifying_information.type. Universal: tin non-US; passport|national_id|other valid for all except USA (ssn|itin only). Examples: cpf (BRA), curp|ine|rfc (MEX), nino|utr (GBR), steuer_id|idnr (DEU), spi (FRA), dni|cuil|cdi (ARG). A separate ~300-row government-photo-ID matrix (passport/DL/national ID/other; extraction vs verification; *=backside required) lives in api.md's "Supported Government ID's by Country" table.
  • Businesses (.../businesses/identification.md): ~180-country table. Universal non-US: other/vat. US sole props: ssn|itin|ein|passport. Non-US sole props: passport|national_id. Mexico requires the Cédula de Identificación Fiscal confirming the RFC.
  • EEA (§4 has field-level detail): national-ID + TIN table by country (FRA nir+spi, DEU steuer_id, ESP nie+nif, NLD bsn); business registration + tax-ID table (FRA siren|siret, DEU crn+ust_idnr, NLD kvk+vat, IRL cro+trn|chy|rcn).
  • Brazil/pix: phone on customer + each associated person, identifying_information.issuing_country, cpf(individuals)/cnpj(businesses) for Brazilians, liveness_check_selfies[], incorporation_date. (.../brl-ramp-migration-guide.md)
  • Postal codes: validated per-country only for the cards endorsement (~180 countries have a regex); unlisted countries skip validation. (.../postal-code-validation.md)

Implications for Stables: a country → {individual ID types, business ID types, doc matrix, postal regex, EEA/BR extra fields} lookup table is the natural shape for a dynamic onboarding form — but per the bridge-development skill, treat this page as a pointer, not a copy source; re-fetch the live tables when building it. Model identifying_information as a list per person/business — multiple ID types is now normal, not an edge case (EEA requires a national ID and a TIN simultaneously).

9. High-risk and prohibited activities​

Must-disclose high-risk activities (fields is_high_risk, high_risk_activities[], conducts_money_services, conducts_money_services_using_bridge, compliance_screening_explanation): Money Services (check cashing, gift cards, ATMs, remittances), Lending or Banking, Operate Foreign Exchange/Virtual Currencies Brokerage/OTC, Hold Client Funds (escrow), Third-Party Payment Processing. Enhanced KYB additionally asks about high-risk geographies (Cuba, Iran, Myanmar, North Korea, Syria) and money-transmission disclosure.

Prohibited by ToS — quoted verbatim from platform/customers/compliance/businesses/highrisk.md because the exact wording matters for a business-model determination (see below):

Unlawful or abusive activity; Unfair, predatory or deceptive practices; Fraud; Games of chance; Gambling; Sweepstakes; Lotteries; Weapons; Precious metals; Jewelry; Watches; Luxury goods; Unlawful prediction markets; Intellectual property infringement; Check cashing; Bail bonds; Collections agencies; Safe Deposit Box Rentals; Counterfeit or unauthorized goods; Cannabis; Cannabis related products and services; Pharmaceuticals; Tobacco products; Substances designed to mimic illegal drugs; Adult content and services; Multi-level marketing; Mixing; Investment or credit services (provided by Users to third parties via Bridge); Digital asset exchange services (provided by Users to third parties via Bridge); Money services (provided by Users to third parties via Bridge); Money transmission services (provided by Users to third parties via Bridge); Any business that Bridge believes poses elevated financial risk, legal liability, or violate Payment Services Provider rules, card network rules or bank policies.

Outcome codes: high_risk_business_activities, rejected_due_to_unsupported_business_activities, operates_in_prohibited_countries.

Implications for Stables: a pre-KYB activity-declaration step must capture the disclosure fields verbatim and pre-screen against the prohibited list before submitting to Bridge — exactly the shape of the D117 activity declaration gate; this page is the authoritative Bridge-side source for that matrix (distinct from Sumsub's or any other vendor's list). Business-model flag: the bolded lines above read as prohibiting Bridge-hosted customers from reselling Bridge-backed money-movement/exchange capability to their own end users — a business-model question for Stables to resolve, not an engineering one (§12).

10. Restricted-customer caps​

Bridge allows a "restricted" individual customer path in the US that skips photo-ID verification, subject to a transaction cap. Confirmed across three pages that the per-transaction cap is $10,000; the aggregate cap and its window are the §7 inconsistency ($100,000 lifetime per individuals.md vs $100,000/30 days per add_req.md and dao.md). Above the cap, photo ID verification is required (requirements_due: ["id_verification"]) via a new hosted URL or a PUT. DAO "Core" customers and standard (non-DAO) businesses carry the same $10,000/txn, $100,000/30-day structure before Enhanced KYB is required (platform/customers/compliance/dao.md, .../businesses/overview.md).

Implications for Stables: a restricted-customer onboarding path (skip photo ID, accept the cap) needs its own limit-enforcement logic distinct from the endorsement/status gates in §5–§6 — a customer can be fully active/approved and still be capped. Do not hardcode the aggregate window (lifetime vs 30-day) without confirming with Bridge first (§12).

11. Supported / prohibited countries​

platform/customers/compliance/supported-countries-list.md is a 251-row table (country/ territory, risk tier, per-rail support columns).

Reading the table: tiers are Prohibited (20 rows — AFG, BLR, COD, CUB, Gaza/West Bank, IRN, IRQ, LBN, LBY, MMR, PRK, RUS, SOM, SSD, SDN, SYR, Ukrainian-occupied territories, VEN, YEM), High (96 — extra diligence/enhanced KYC-KYB), Medium (83), Low (52). A handful of High-tier countries carry "No" across every rail column (Algeria, Burundi, China, Guinea-Bissau, Japan, Tunisia) — risk-tiered but not actually onboardable; read tier + rail columns together. Rail columns: US ACH/FedWire, SEPA (EUR), FPS (GBP), SPEI/PIX/Bre-B, Crypto-to-Crypto, Custodial wallets — non-uniform even within a tier (e.g. no US ACH for BGD, HTI, KEN, MOZ, NPL, NER, PAK, ZWE, BTN, XKX, MAR, QAT; no SEPA/FPS for CAF, ERI, MLI; no custodial wallets for IDN, THA, HKG, MYS, AUS, NZL, SGP).

US-specific: excluded when the principal residential/operating address is in New York (NY incorporation with operations elsewhere is fine, with proof of address); Florida and Louisiana are now supported. Missing codes subdivision_not_ny_usa/subdivision_not_ak_usa (§6) imply Alaska is gated too, though the countries-list page itself is silent on Alaska.

This table governs onboarding eligibility by residence/incorporation country — not which countries a transaction can move money to (the rail-specific page, platform/orchestration/more/rail-specific.md, out of this digest's scope).

Implications for Stables: keep a versioned copy of the tier/rail table (re-fetch per the bridge-development skill's freshness discipline rather than assuming these counts stay current) — gate onboarding intake by residence/incorporation country + US state before submitting to Bridge, not after a rejection; drive enhanced-KYC/KYB prompting off the High tier; surface endorsement_not_available_in_customers_region explicitly rather than a generic error.

12. Open questions for Bridge​

Consolidated + tracked in flow-alignment.md §Open questions; this section keeps this page's own detail.

  • Is the restricted-US-customer aggregate cap $100,000 lifetime or $100,000 per 30-day period? Individuals page says lifetime; add_req and DAO pages say 30-day (§7, §10).
  • Correct field name for a business's beneficial owners at customer creation: ultimate_beneficial_owners[] (api.md create example) or associated_persons[] (every other page + the dedicated sub-resource)? (§7)
  • Is there a standalone "request/add an endorsement on an existing customer via the Customers API" endpoint? Implied by the BRL page's phrasing, not shown in platform/customers/* (§6).
  • Do ToS links or KYC links expire, and if so after how long? Not stated on any fetched page (§3).
  • Full enum values for business_type, account_purpose, source_of_funds, employment_status, expected_monthly_payments, estimated_annual_revenue_usd, high_risk_activities? Only single examples appear in platform/customers/*.
  • Does the ToS-prohibited-activities clause on "Investment or credit services / Digital asset exchange services / Money services / Money transmission services (provided by Users to third parties via Bridge)" (§9) actually prohibit Stables' own business model of offering Bridge-backed money movement to Stables' tenants/customers? Needs a direct answer from Bridge, not an inference from the docs.
  • What are the requirements specific to the cards endorsement? Only postal-code validation is documented under platform/customers/*; the rest presumably lives under platform/cards/*.
  • Rate limits and PII retention periods for customer/KYC data are not stated on any fetched page.

13. Fetched 2026-09-03​

Full URL list (all under https://apidocs.bridge.xyz/), llms.txt-indexed pages plus three linked pages not in the index (EEA updated requirements, business industry codes, SEPA/Euro transactions):

platform/customers/overview.md
platform/customers/customers/api.md
platform/customers/customers/kyclinks.md
platform/customers/customers/add_req.md
platform/customers/customers/endorsements.md
platform/customers/customers/tos.md
platform/customers/customers/rejection_reasons.md
platform/customers/customers/missing-requirements-and-issues.md
platform/customers/customers/brl-ramp-migration-guide.md
platform/customers/customers/postal-code-validation.md
platform/customers/customers/eea-updated-requirements.md
platform/customers/customers/sepa-euro-transactions.md
platform/customers/compliance/individuals.md
platform/customers/compliance/businesses/overview.md
platform/customers/compliance/businesses/entity.md
platform/customers/compliance/businesses/ownership.md
platform/customers/compliance/businesses/formation.md
platform/customers/compliance/businesses/identification.md
platform/customers/compliance/businesses/highrisk.md
platform/customers/compliance/dao.md
platform/customers/compliance/docs.md
platform/customers/compliance/poa.md
platform/customers/compliance/supported-countries-list.md
platform/customers/compliance/business-industry-list-updated-2022-naics-codes.md

← Bridge cluster index · ← Engineering wiki