Risk does not stop at onboarding

Executive position

A verified customer can still be compromised, coerced, or fraudulent

Identity evidence is necessary, but it is not a permanent declaration that every future session and payment is safe. Credentials can be stolen. A genuine customer can be coached through a scam. An apparently normal account can receive mule proceeds. Reversible card or bank funding can be converted into stablecoins and withdrawn before a later chargeback or return arrives.

In the setups I have led, I use Sardine as the specialist signal and rule layer. Its web and native Risk SDK, device and behavioral signals, supervised and anomaly-detection models, real-time no-code rules, shadow mode, and unified dashboard provide the working surface. I keep the final decision, durable restriction, customer communication, and proof of enforcement inside the stablecoin neobank. Sardine: What powers Sardine

Capability map

What Sardine can contribute to the control stack

Sardine also supports identity, KYC, KYB, screening, case management, and broader compliance capabilities. Sumsub likewise offers fraud-prevention and transaction-monitoring products. The split in this series is not a claim of vendor exclusivity; it is the operating model I use to minimize duplicated rules and ambiguous ownership.

Decision boundary

Put rules where the signals live—and actions where the product is authoritative

Rebuilding Sardine’s device, behavior, transaction-velocity, and fraud-threshold rules inside a second engine creates two versions of truth. Instead, consume stable rule identifiers, reason codes, disposition, model metadata, and evidence time. Reserve internal rules for facts only the platform can authoritatively know or enforce.

Execution profiles

Place the risk check according to reversibility and deadline

Architecture recommendation “Always call the risk vendor synchronously” is not a safe universal rule. The correct route depends on whether the action can be reversed, how quickly the external rail needs an answer, and whether delay itself increases exposure.

An asynchronous result cannot retroactively decline a completed card authorization. It can open a case, support a permitted reversal or refund process, restrict the next attempt, or trigger recovery controls. Keeping that distinction explicit prevents analysts and engineers from designing impossible “release” actions for already-expired or completed rail events.

At a crypto withdrawal, I screen the destination wallet or transaction with Elliptic Lens, retain the screening identifier and exposure detail, and pass the normalized Lens score into Sardine as custom transaction evidence. Sardine can then evaluate that on-chain risk alongside the current device, behavior, account history, amount, and velocity before the internal policy gate acts. This is an orchestration pattern, not a claim of a packaged Sardine–Elliptic integration. Elliptic Lens

Interactive routes

See where the risk decision belongs

Threat journeys

Connect signals to the loss mechanism

1. Reversible funding becomes irreversible value

Sardine defines payment-funding risk as the possibility that a card or bank payment is later reversed after provisional funds have already been spent or withdrawn. In a stablecoin product, the dangerous boundary is the moment reversible funding becomes transferable or leaves through an irreversible rail. A ledger status such as authorized must not be treated as economic finality unless the business deliberately accepts and prices that exposure. Sardine: Payment fraud

2. Account takeover precedes a new destination

I link Sardine’s device, IP, network, session, account-change, and transaction-pattern signals to the full sequence: suspicious login, contact-detail change, beneficiary or wallet creation, step-up attempt, and withdrawal. Blocking only the final transfer discards useful earlier intervention points. Sardine: Account takeover

3. A genuine customer is coached through a scam

An authorized push-payment scam differs from stolen-credential fraud because the customer approves the payment. I combine Sardine’s unusual pauses, copy-paste behavior, typing patterns, and remote-access indicators with a first-time payee, unusual amount, or out-of-pattern timing. That evidence supports targeted step-up or a cooling-off treatment rather than a generic high-value decline.

4. Mule activity crosses accounts and products

A mule account may receive proceeds, layer them through internal transfers or conversions, and withdraw them. I therefore build transaction monitoring from customer history, cohort context, linked entities, and the complete event lifecycle—not only settled transactions. Sardine can build behavioral profiles from deposits, peer-to-peer transfers, withdrawals, and platform interactions. Sardine: Transaction monitoring

5. A late signal changes the future, not the past

If an asynchronous card result arrives after authorization, preserve both facts: the rail response completed, and later evidence was high risk. Open the appropriate review, restrict the next card attempt or outward movement where policy permits, and retain the event relationship. Never rewrite history to make the audit trail look simpler.

Rules and operations

Treat every enforced rule as a managed product

I use Sardine’s real-time no-code rules and shadow mode inside a governed release process. Every rule still needs an owner, rationale, target event, data dependencies, version, effective date, review or expiry date, expected customer impact, and rollback path.

Send truthful context

A fraud model is limited by the event contract. Send stable customer and transaction identifiers, actual device or session context when it exists, event type, amount, currency or asset, counterparty and rail facts, relevant lifecycle status, and eventual outcome. Do not claim that an old app session was present for a physical card purchase or an externally initiated transaction.

Separate four action scopes

• Transaction: approve, step up, hold, decline, monitor, or reverse where the rail genuinely supports it.
• Feature: restrict withdrawals, cards, trading, beneficiary creation, or limit increases.
• Account: apply a temporary security lock, suspension, legal restriction, or relationship exit under the appropriate authority.
• Case: create an alert, investigation, RFI, enhanced review, or reporting candidate without silently changing product access.

Design the outage before launch

Rail-critical paths that normally evaluate Sardine asynchronously can continue under approved internal and processor controls while events queue in a durable outbox. An irreversible or exposure-changing action that requires current evidence needs a separate fail-safe treatment. Track queue age, missing SDK coverage, timeouts, stale results, enforcement failures, and reconciliation backlog as control metrics.

Regional applicability

The signal layer can travel; the decision policy cannot

Regulatory lens Device, behavior, and transaction telemetry can support several markets, but collection, retention, model governance, authentication, monitoring, reporting, and customer-action rules must be approved for each operating entity and jurisdiction.

The table is deliberately a control-design prompt rather than a legal summary. “Asia” and “MENA” are not regulatory regimes, and even UK, EU, and US programmes may involve several differently accountable entities and partners.

Delivery checklist

What executives should require before production

Measure control quality and customer cost together: prevented loss, confirmed fraud, chargebacks or returns, approval rate, false positives, challenge completion, abandonment, support contact, case age, restriction duration, and enforcement failure. A risk programme that cannot explain its customer impact is not production-ready.

Primary reading

Sources used for this reference architecture

1. Sardine: What powers Sardine — Risk SDK, device and behavioral signals, supervised and anomaly models, rules, shadow mode, and dashboard.
2. Sardine: Account takeover — device, network, behavior, account-change, and transaction-pattern signals.
3. Sardine: Payment fraud — card, bank, ACH, APP-scam, behavioral, and targeted-friction patterns.
4. Sardine: Transaction monitoring — behavioral profiles, anomalous transaction detection, and configurable rules.
5. Elliptic Lens — real-time wallet and transaction screening, exposure detail, configurable risk scores, and pre-withdrawal screening.
6. Sardine: Novo customer story — a vendor-published example of device, behavior, rules, and targeted step-up in a neobank context; outcomes are vendor-reported, not a benchmark.
7. 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 risk configuration meets every jurisdiction’s requirements. Product claims describe official documentation checked on 8 September 2026; availability, data fields, model behavior, latency, and contractual scope should be confirmed directly with Sardine.