Executive position
Buy specialist evidence. Keep the banking decision.
“Stablecoin neobank” is useful product shorthand, not a regulatory category. The operating entity may be a bank, electronic-money or payment institution, money services business, crypto-asset service provider, virtual-asset service provider, or a programme that combines several licensed partners. That distinction changes which checks are required, who may hold customer money, and who is accountable when a control fails.
In the setups I have led, the durable product strategy is not “Sumsub approved the customer.” It is: “Sumsub supplied evidence from the checks we configured; our platform evaluated that evidence against the entity, market, partner, product, and risk policy in force.” Sumsub can combine identity documents, biometrics, database validation, screening, rules, and manual review in a user-verification workflow, with results available through its dashboard, API, or webhooks. I keep the relationship and product decision inside the regulated business. Sumsub: User Verification
Sumsub is authoritative for the evidence produced by its configured checks. The neobank is authoritative for customer acceptance, feature eligibility, restrictions, appeals, and release.
Capability map
What Sumsub can contribute to the control stack
Vendor capability Sumsub provides a broad verification and monitoring platform. I do not enable every available check by default; I select the smallest evidence set that fits the customer, action, and jurisdiction.
User verification
Configured flows may combine identity information and documents, liveness or other biometric checks, data cross-checks, AML screening, rules, and manual review. Sumsub supports web, mobile, link-based, and API-led integration patterns.
Business verification
For KYB, I use Sumsub to establish the company’s structure, ownership, purpose, and activities, collect and verify company and beneficiary information, and link the natural-person checks the programme requires.
AML screening
Applicants, counterparties, and transaction counterparties—people or legal entities—can be screened using configured sanctions, PEP, watchlist, and adverse-media sources, with selectable matching settings.
Ongoing monitoring
I treat ongoing monitoring as a lifecycle input: after an AML screen, Sumsub can update an applicant profile when relevant source information changes. I confirm the exact status behavior and commercial coverage for the contracted account.
Transaction monitoring
I submit transaction data for monitoring and scoring when the control design calls for it, then consume the resulting rules, alerts, counterparty screening, review, and configured actions. Required fields and runtime handling depend on the transaction type and implementation.
Travel Rule workflows
I configure the Travel Rule workflow around the programme’s obligations: exchanges, timeouts, incoming wallet-ownership verification, comparison settings, counterparty screening, and, where appropriate, unhosted-wallet verification.
These capabilities overlap with services available from other vendors, including Sardine. My division of responsibility is an architectural choice: I use Sumsub as the primary identity, business-verification, and named-party screening evidence source, then avoid recreating its workflow inside the neobank.
Decision boundary
Verification results should update evidence—not become product permissions
Sumsub evidence
- Applicant, company, inspection, and workflow identifiers
- Configured document, biometric, registry, and screening results
- Provider status, review result, labels, and observed time
- Associated-person and company-structure evidence within the selected KYB flow
- Monitoring and review events emitted by the provider
Neobank decisions
- Which legal entity and programme may serve the customer
- Account, card, fiat, wallet, trading, and withdrawal eligibility
- Limits, transaction holds, feature restrictions, and account actions
- Customer communication, RFI, appeal, and complaint handling
- Policy version, decision evidence, enforcement confirmation, and release
A provider-approved result answers the configured verification question at a point in time. It does not establish that every programme supports the customer’s residency, that a linked bank account belongs to them, that a stablecoin destination is safe, or that no later restriction exists. Likewise, a potential AML match should remain a potential match until it is resolved under approved procedures; it should not be described to staff or customers as confirmed criminality.
For a business, keep identity, ownership, authority, and account access separate. A verified director or beneficial owner is not automatically an authorized platform user or transaction approver. Model the company and its relationships as a versioned graph, then grant capabilities through a separate entitlement model.
Interactive model
Follow evidence as it becomes a product decision
Evidence-to-entitlement map
Change the scenario to see why customer, company, and lifecycle evidence must pass through an internal policy gate.
Reference architecture
Normalize evidence, version decisions, and confirm enforcement
Use a typed evidence record
Do not reduce the provider result to kycPassed: true. Retain the provider, subject, workflow or level, relevant result categories, observed and received times, evidence freshness, payload digest, and source identifiers. Store raw restricted material separately from normalized facts and customer-facing state. The decision record should add the policy version, reasons, scope, reviewer where relevant, and enforcement status.
Treat the browser and mobile SDK as collection surfaces
The client-side completion callback is useful for progress and navigation; it should not grant a bank account, card, wallet, or withdrawal. Final product state should follow authenticated backend evidence and the internal decision. API secrets and request signing remain on the server.
Assume delivery is imperfect
Webhooks may be duplicated, delayed, or delivered around a retry. Verify authenticity using the provider’s documented method, acknowledge quickly, process from a durable queue, and reconcile important states with the API. A newly received event should trigger an eligibility recomputation rather than directly editing several products in unrelated code paths. Sumsub: Webhook manager
Product journeys
Apply the evidence at the moment it changes exposure
| Journey | Relevant Sumsub evidence | Additional platform decision | Safe failure posture |
|---|---|---|---|
| Consumer onboarding | Configured identity, biometric, address, and AML results | Entity, country, age, product, partner, duplicate, and internal-risk eligibility | Keep a resumable onboarding shell; do not provision regulated features |
| Business onboarding | Company, registry, ownership, associated-person, document, and screening evidence | Relationship acceptance, authority to act, member roles, mandates, and capability-level access | Show the blocking dependency; keep unresolved capabilities gated |
| Card or fiat account | Current accepted customer or business evidence | Issuer or banking-partner rules, residency, account-name, and programme restrictions | Do not issue unusable credentials; preserve unrelated eligible capabilities |
| Stablecoin deposit | Current customer status and named-party evidence where required | Network confirmation, wallet and transaction screening, attribution, and availability policy | Show pending; do not make funds available before mandatory checks complete |
| Stablecoin withdrawal | Current status, counterparty screening, and Travel Rule data where applicable | Balance, limits, destination risk, authentication, custody, and jurisdictional policy | Hold before broadcast when a mandatory pre-release check is unresolved |
| Higher limits | Required updated or enhanced customer evidence | Source-of-funds or wealth policy, fraud posture, expected activity, and approval authority | Keep the existing lower limit when safe; do not erase valid evidence unnecessarily |
Travel Rule information, customer verification, named-party screening, and blockchain analytics answer different questions. Sumsub’s own Travel Rule FAQ distinguishes KYC, AML screening, and the inter-firm transfer of originator and beneficiary information. Treat them as related evidence sets, not interchangeable controls. Sumsub: Travel Rule FAQ
Beyond onboarding
Build one evidence-update loop for the whole relationship
Identity and business verification decay. Documents expire, company ownership changes, screening sources change, expected activity diverges from observed behavior, and customers request higher-risk capabilities. Use the same sequence for every material update: ingest evidence, normalize it, evaluate current policy, apply the narrowest sufficient action, and confirm enforcement.
- Document expiry: notify early, provide a direct renewal path, and map the expiry to the capabilities it actually affects.
- Screening alert: preserve match details and resolution status, route review, and avoid translating an unresolved match into an unsupported accusation.
- Business change: version the ownership and control graph; re-evaluate associated persons, authority, and product access.
- Product expansion: collect only the additional evidence required for the new assurance need.
- Relationship exit: separate the decision to stop future service from the controlled handling of existing money, records, reports, and customer communication.
Sumsub supports ongoing AML monitoring and periodic or event-driven verification features, with availability and exact behavior determined by configuration and contract. In the product requirements, I record which checks are active, for whom, and what happens if they stop or become unavailable—not merely that “continuous monitoring” exists.
Regional applicability
Keep the architecture global and the policy local
Regulatory lens The same evidence pipeline can serve several regions, but the rules, accountable entity, required data, timing, and customer treatment cannot be copied from one market to another.
| Region | Design question for the programme | Primary reference starting point |
|---|---|---|
| UK | Which activities fall inside the current AML registration framework, the incoming authorization regime, payments or e-money rules, and the UK Travel Rule? Model current and future effective dates separately. | FCA cryptoasset information |
| European Union | Which entity is the CASP or payment-service provider, and how do MiCA authorization, AML controls, and originator/beneficiary information requirements apply to each transfer? | EU Regulation 2023/1113 |
| United States | Map the exact activity to federal BSA/MSB treatment, sanctions, applicable state licensing, partner-bank responsibilities, and the chosen card or bank rail. | FinCEN virtual-currency guidance |
| Asia | Avoid an “Asia configuration.” Build country-level policy packs for customer type, product, token, custody, transfer, screening, and ongoing-monitoring requirements. | Hong Kong SFC example |
| MENA | Identify the actual national or financial-free-zone regulator, licensed activity, local AML framework, data treatment, and any product-specific rulebook before configuring a shared workflow. | Dubai VARA example |
This table is a routing aid, not a legal comparison. Asia and MENA contain materially different national and free-zone regimes. Legal and compliance owners should maintain a versioned policy matrix for each entity, market, customer type, product, and effective date.
Delivery checklist
What executives should require before production
Product and governance
- Named owner for every verification level and screening configuration
- Documented entity, market, product, and partner perimeter
- Approved match-resolution, RFI, appeal, restriction, and exit treatment
- Vendor change, outage, subprocessor, retention, residency, and access review
- Metrics for completion, false positives, review time, complaints, and restriction duration
Engineering and operations
- Immutable internal subject IDs mapped to provider identifiers
- Server-side secrets, authenticated webhooks, idempotency, and reconciliation
- Separate stores for raw evidence, normalized facts, decisions, and enforcement
- Feature-level entitlements with explicit pending and restriction states
- Golden tests for retries, late events, later alerts, outages, and release
Architecture recommendation The control is complete only when the product service confirms that the requested grant, hold, or restriction was actually applied. A dashboard decision or emitted event is not proof of enforcement.
Primary reading
Sources used for this reference architecture
- Sumsub User Verification — workflow components, integration routes, checks, rules, results, and review.
- Sumsub Business Verification — company structure, ownership, beneficiaries, and screening.
- Sumsub AML screening and monitoring and configuration guidance.
- Sumsub ongoing AML monitoring — lifecycle behavior, status treatment, and configuration cautions.
- Sumsub transaction submission API — transaction monitoring and scoring integration.
- Sumsub transaction and Travel Rule settings and Travel Rule FAQ.
- Sumsub Webhook manager — webhook authentication and delivery guidance.
- UK FCA, EUR-Lex, FinCEN, Hong Kong SFC, and Dubai VARA — primary regulatory starting points.
This article is product and architecture guidance, not legal advice or a statement that one configuration meets every jurisdiction’s requirements. Product claims describe official documentation checked on 8 September 2026; availability and contractual scope should be confirmed directly with Sumsub.
Continue to part 2 Risk does not stop at onboarding: Sardine’s role in a stablecoin neobank Connect verified identity to device, behavior, payment, account-takeover, and transaction-risk controls.