Sardine: fraud signals, onboarding checks and AML workflows

Sardine provides a connected fraud and financial-crime platform across account creation, customer activity and payments. Its catalogue combines device and behavioural signals, identity checks, payment-risk analysis, AML monitoring and investigation tools. For a financial-service operator, the commercial use is to make these signals available within the same decision process, so an apparently valid identity or bank account can also be assessed in the context of how it is being used.[1]

Transaction monitoring combines scenarios for structuring, rapid movement of funds, layering and other suspicious patterns with customer history and relationship analysis. The graph connects users, devices, IP addresses, counterparties and transactions, allowing an investigator to move from an isolated alert to related activity. Thresholds can be adjusted by segment and tested against historical records. These functions help organise the evidence for a decision; a suspicious pattern still needs interpretation in its customer and business context.[6]

Sanctions screening covers initial checks, transaction parties and subsequent changes in customer or watchlist information. Sardine describes configurable matching factors and thresholds, including testing before deployment, and preserving the reasoning behind escalated matches. Its AI can clear selected lower-risk cases or recommend a decision for an analyst under the configured procedure. The institution can therefore make the automation boundary explicit rather than treating every match as either an automatic rejection or an identical manual review.[7]

Case management joins alert queues, entities, transactions, evidence and decisions. Queues can have assignments, escalation rules and service-level tracking, while granular permissions control who reviews and resolves a case. The platform also supports SAR narratives and reporting workflows linked to the investigation record. The important operational connection is between the original trigger and the eventual disposition: reviewer actions and supporting evidence remain part of the same case history.[8]

The public technical guide describes a Risk SDK for web and native applications. It supplies device and session information used alongside machine-learning models and configurable rules. A hosted dashboard exposes identity results, checkpoints, queues, reporting and user controls. Integrating the SDK supplies a different category of evidence from sending transaction records: one describes the customer session, while the other describes the financial activity to be evaluated. Both need to be linked to the relevant customer and event.[9]

Sardine’s KYC page describes deployment as a full orchestration platform or as a decision layer around existing vendors. API connections can preserve downstream AML, screening and case-management systems. This supports incremental implementation, although the public product page does not establish compatibility with every version of a named third-party system.[3]

Sonar Insights accepts identifiers such as names, contact details, IP addresses, bank information or wallet data and returns structured counterparty signals. Configurable data packs combine different types of fraud, AML and credit information. The integration therefore needs a defined purpose and selected response fields; the existence of a broad consortium does not mean every participant receives every data category or the same permissions.[10]

The public commercial route is a personalised demonstration and sales enquiry. No numeric subscription tariff, standard setup charge or universal minimum commitment is published on that page. The quotation must identify the selected capabilities and service scope before an operating cost can be compared.[12]

Getting started requires a sandbox account arranged through a Sardine representative. Once it is issued, administrators can invite dashboard users and assign roles with different permissions. The same onboarding route provides access to integration guides and API documentation. This is a controlled provisioning process rather than an anonymous self-service API trial; the public guide does not give a universal production-onboarding timetable.[13]

The rules engine provides historical backtesting, shadow execution against live traffic and A/B comparison. Its published analytics include precision, recall and the frequency with which rules fire. These measurements answer different questions: a rule can detect more suspected fraud while also producing more customer friction or investigation work. Comparing outcomes before enforcement is therefore part of implementation, not just a later reporting exercise. Configurable workflows then determine when to request another check, approve, route or escalate.[14]

For custom agents, Sardine describes engineers working with the customer to map data, decision logic, integrations and operating guardrails. The sequence moves from choosing a workflow to testing real cases and refining outputs, followed by ongoing adjustment. The page’s delivery language is an advertised process; it is not a fixed completion date for every integration.[11]

The security page directs enterprise reviewers to a trust centre for SOC 2, penetration-test and other security documentation. It separately provides a vulnerability-reporting route. A public link to an audit document is different from reviewing its scope and exceptions, so the contractual security assessment needs the actual materials relevant to the chosen service. The public page alone does not set a data-residency or recovery-time commitment.[15]

Customer access and product discussions are routed through an account representative or the public contact form. The contact page does not state a universal support-hours schedule, response target or escalation timetable. Those details need to be attached to the contracted service rather than inferred from customer testimonials.[12]

The status service separates components including device, customer, issuing and business APIs from the dashboard and external providers. It publishes incident history and offers subscription channels. That separation is useful operationally: a dashboard problem and an online risk-evaluation problem need not have the same impact. The status page is a current communication channel, not a contractual availability guarantee.[16]

The monitoring documentation describes software consuming customer-platform transaction data and applying rules to behavioural patterns. That is the technology role covered by this profile. A brokerage using the output remains responsible for its own regulated business, customer decisions and applicable reporting process; buying a risk tool is not evidence that those obligations have transferred to the supplier.[18]

The privacy policy excludes data processed for enterprise customers from its general scope and says that processing is governed by their contracts. The customer’s own privacy notice governs its collection and use. Retention, permitted processing and an exit export therefore need to be established in the enterprise agreement.[17]

Sonar describes itself as an independent consortium with governance rules, member participation and separate API documentation. This operating model should be distinguished from the underlying corporate relationships: membership, data contribution and access are governed arrangements. A participant’s use of shared intelligence must fit its agreed scope; a marketing description of legal frameworks does not authorise unrestricted exchange of customer information.[20]

The privacy policy identifies SardineAI Corp. and names SonarAI LLC and SardineAI Payments, Inc. among its affiliates. Those identities are relevant when resolving the contracting service. The policy provides a Miami postal contact, but that address alone is not used here to establish the location of every operating team.[17]

Sardine’s company page identifies Soups Ranjan as chief executive and co-founder, Zahid Shaikh as chief product officer and Aditya Goel as a co-founder. Its stated customers include banks, fintechs, marketplaces and merchants. The same page describes Sonar as its consortium network, reflecting a product strategy that connects a firm’s internal risk records with signals from the wider payments ecosystem.[19]

Operator

SardineAI Corp.

Service scope

Fraud prevention, identity and business verification, payment-risk checks, AML monitoring, case management and risk-workflow automation.

Customer types

Banks; Fintechs; Marketplaces; Merchants

Delivery

Hosted; API

Pricing publication

Quote only

Platforms

Device and Behavior Intelligence; KYC Onboarding; KYB; Bank Account Owner Validation; AML Transaction Monitoring; Sanctions Screening; Case Management; Rules Engine; Custom Risk Agents; Sonar Consortium

Integrations

Web Risk SDK; Native-app Risk SDK; Risk-data APIs; Sonar Insights API; API connections to existing KYC and AML systems; Embedded Sardine dashboard

Pricing scope

No public numeric platform tariff; Custom Risk Agents describe usage-based charging without a published rate.

Implementation

Representative-provisioned sandbox, dashboard roles, web/native Risk SDK and API integration; deeper guides require access.

Support

Account representative and public enquiry route; component status and incident subscriptions are published. Contractual response targets are not stated on the reviewed contact page.

Permissions and regulatory scope

Risk software supports customers’ fraud and AML processes. This profile does not assign financial permissions to the technology offering or extend a payment affiliate’s possible activity to the group.

Provider metadata checked 21 Oct 2026Source 19Source 21Source 11Source 5Source 8Source 10Source 12Source 9Source 2Source 18Source 1Source 4Source 3Source 6Source 17Source 14Source 7Source 20Source 13Source 16Source 23

ACH indemnification has a specific published boundary: the documentation lists unauthorised return codes R05, R07, R10, R11 and R29, and says Sardine usually needs around three months of ACH transaction data before considering the add-on. It is therefore a separately assessed arrangement, not an automatic feature of every bank-verification check or a guarantee against every reason a payment might fail.[21]

The card guarantee overview concerns fraud liabilities on card transactions and describes combining transaction-specific models with configurable rules. It does not set out a universal indemnity amount, all eligible dispute categories or a complete claims procedure. A commercial buyer needs those definitions in the agreement before treating the product as transferring a particular loss exposure.[22]

The June 2026 product update, published on 1 July, describes embedded dashboard views, transaction-level screening configuration, alert checklists and an alert-history tab. The checklists can require defined investigation steps before an alert is resolved, while embedded views place the risk information in an institution’s existing internal tools. These are concrete changes to how teams use the platform: they connect configured policy with the actions and evidence retained during a review.[23]