Security Portal

Contact Us

Sardine

Getting Started

Integration

API Reference

Knowledge Base

Book a demo

Risk includes both fraud and compliance, and if each area is not monitored, it can be a major risk to your bottom line. Here are some common areas of risk that you should be protected against

Common Risk Problems

What Powers Sardine

Overview

Getting Started With Risk

Integration Overview

This guide explains Sardine's billing process and how Sardine bills for different products and services

How Sardine Bills

We provide a combination of both public and protected documentation. You are currently viewing our public page.

Get Full Documentation Access

Identity Fraud, KYC & AML

Account Takeover

Business Verification (KYB)

Issued Card Fraud

Payment Fraud

Sardine can guarantee you against **fraud liabilities** on ACH debits. We can indemnify for only unauthorized returns (R05, R07, R10, R11 & R29).

ACH Indemnification

Card Chargeback Guarantee

Transaction Monitoring

API Authentication

Checkpoints are rulesets designed for specific flows. By default, we provide 250+ rules contained in numerous checkpoints. One to many checkpoints can be invoked in the /customers API request. When a checkpoint is specified in the API request, the rules contained within the checkpoint are applied. If no checkpoint array is defined, we will default the request to the `customer` checkpoint.

Checkpoints

CSP Information

Data Signals

Upload batch files

Go-live Checklist

Orchestrating step up in issuing/risks API

Sardine offers a PCI-compliant `/v1/customers` endpoint to accept RAW card numbers.

Sharing raw credit card numbers (PAN) with sardine

Rate Limit Policy

Reason Codes

In some cases, requests may reach the Sardine load balancer but do not reach the application. The load balancer does not have access to the `sessionKey`.  Therefore, it is difficult to troubleshoot.

Request ID header

Reason Codes and Retry

RulesEditor

Session Key Design

Getting Started with the Integration

Syntax Guide

Test data

Transaction ID

Webhooks

Android SDK

Swift iOS SDK

You can download sample project & SDKs from [here](/guides/integration/riskSDK/mobileSDKs/changelogs/flutter).

Flutter

You can download sample project and SDKs from [here](/guides/integration/riskSDK/mobileSDKs/changelogs/reactNative).

ReactNative (iOS/Android) SDK

ReactNative Expo (iOS/Android) SDK

Xamarin SDK

JetPack Compose

You can download sample project & SDKs from [here](/guides/integration/riskSDK/mobileSDKs/changelogs/cordova).

Cordova Integration

VGS Support

Mobile API

JS SDK Integration via npm

Next JS

React JS

JS SDK Manual Integration

The Custom Subdomain Integration will help you (Sardine's customer) with custom subdomain support when loading Sardine’s SDK. This allows you to hide the fact that Sardine is being used for device intelligence from your customers.

Custom Subdomain Integration Guide

This document is applicable only if you are using VGS. VGS is commonly used to handle sensitive fields like credit card fields to avoid PCI compliance.

VGS Integration

Sardine is a one-stop shop for all of your fraud and compliance use-cases. There are a plethora of ways to pipe in data, checks you can perform, and tools to understand and analyze data.

Sardine Getting Started Guide

In the case that Sardine’s API doesn’t have a field that you’d like to have available you can send that data via a custom field.

Custom Fields

In considering what integration option is best for you, we’ll outline the features of each integration option below.

Sardine Integration Options

When calling the /v1/customers or /v2/devices API’s, the API data you send is matched up with device data collected by a Web or iOS/Android SDK.

Troubleshooting Missing Device Data

Sardine's security posture

Sardine has three different channels for you to get in touch when in need of technical support.

Sardine Support Channels

Click the link below to watch our 5 minute introduction video for the Sardine Dashboard.

Introduction to dashboard

Click the link below to watch our 5 minute video to integrate the Sardine SDK and make a request to the Customer API.

Integrate the Sardine SDK

Click the link below to watch our 5 minute video to set a shadow rule to live and add sessions to queues.

Set Shadow Rule to Live

If you are an admin under the "Admin" page.

Add, update, and remove users

You can access audit logs via admin > audit logs. Audit logs can be searched via user's email, action type, etc.

Audit Logs

Create a queue

While Sardine has a comprehensive breadth of checkpoints (customer, aml, etc.), it may not cover all of the use-cases that you want to handle during a flow with your application.

Creating Custom Checkpoint

Sardine has a functionality to manage custom client lists that can be referenced in _customer_ and _issuing_risk_ checkpoint rule conditions.

Creating Custom Lists

A powerful aspect of Sardine is the ability to detect suspicious connections between your users/customers.

Investigating Connected Users in the Sardine Dashboard

Length of time Sardine retains data

Length of time to refresh data

Sardine supports three login options to dashboard

Login options

This guide walks through how to enable SCIM (System for Cross-domain Identity Management) via WorkOS Directory Sync, specifically for users who already have SSO enabled.

SCIM Set Up Guide

Sardine’s platform offers a consolidated dashboard that provides real-time views into risk scores for individual sessions and users as they take actions, including logins, account openings, payments, and withdrawals. Our dashboard enables role-based access controls for admins, managers, and analysts with scoped access to sensitive data.

Navigating the dashboard

Sardine’s subaccount feature allows merchants, banks, and fintechs to leverage parent-child account behavior, providing an option to set up accounts with a hierarchical structure.

Parent - Child Behavior

Revoke API credentials

The accuracy is calculated based on the formula (number of keys pressed - number of backspaces)/(number of keys pressed), so a value of 1 means that the user typed with 100% accuracy -- without any backspace to fix the mistyped character. Any value less than 1 means the user used backspaces to correct the values typed.

Typing accuracy

You can upload batch feedback (as a CSV file) under the Feedback section in the dashboard or input manually for an individual session by clicking on the "Add Feedback > Add manually" dropdown at the top of a session page.

Update feedback via CSV file

Using the Network Graph

While creating and editing a rule, you can perform a backtest for the rule to view summary performance statistics and a sample of customers and sessions. This way, you can sanity-check the rule’s efficacy before deploying it to your ruleset.

Backtesting during Rule Addition and Edition

A default Sardine rule requires copying the rule to your organization of rules and disabling the original default rule.

Duplicating a default rule

A rule is a predefined set of criteria or conditions that, when met, indicate potential fraudulent activity.

Rules and Templates Management

Rules Editor

Score Sum Rule Evaluation

A rule that is in "shadow" does not trigger an action tag for low, medium_low, medium, high, or very_high risk level.

Shadow vs live rules

Sanctions, PEP, and Adverse Media checks can be performed by calling the /v1/customer API.

AML Reference

The Alert details page is a page that aggregates all Alert information in one place, making it easier to investigate and make decisions for a single Alert.

Alert Details Page

Sardine offers a robust alert management system that allows you to set up multiple review queues, add & assign review alerts, and make real-time decisions on those alerts with collaboration with others.

Alert Review Queues

US Business Verification

Sardine’s Routines feature is an advanced look back and aggregation capability designed to augment Sardine’s real-time aggregations and rule execution with the ability to run asynchronous “Routines”. These batch jobs leverage a SQL-like query interface and can be scheduled one-time or recurring to address common AML use cases such as structuring.

Batch Routines

This document explains how to utilize Sardine’s platform for Anti-Money-Laundering (AML) Transaction Monitoring and Case Management.

AML Transaction Monitoring

Information about a credit or debit card can be garnered from the first 6 or 8 digits of the card (the card BIN).

Card BIN Enrichment Signals

Sardine offers a feature to verify card identity with customer's name, address and date of birth.

Card Identity Verification

A fingerprint is a hash of various device attributes Sardine receives from the JavaScript (Web/Browser) or mobile (iOS/Android) SDKs.

Device Fingerprint

Sardine provides document verification through 3rd-party partners.

Document KYC Signals

If you have email enrichment (also called ‘foundational fraud’) in your Sardine contract then when you pass Sardine an email in the /v1/customer API we will gather more information on it from external sources.

Email Risk Signals

Proxies can operate at various layers of the network stack, including application layer proxies like HTTP proxies and network layer proxies like SOCKS proxies.

Proxy

Detecting Account Takeover

If you have SSN Verification and Synthetic ID Detection in your contract you can use Sardine to enrich a user’s SSN for risk and compliance purposes.

SSN/Tax ID Enrichment

Sardine provides a plethora of data around rule behavior and efficacy.

Understanding Rule Performance

new capability to detect App Clip(iOS) and Instant App(Android)

App Clip & Instant App Limitations

The most common **Action Tag** is the riskLevel action tag (`low`, `medium`, `high`, and `very_high`), this defines the overall risk level of the session.

Action Tags/Risk Level

Sardine has functionality to block or allowlist a variety of data points to allow you to accomplish business or fraud prevention goals. This document will outline the mechanics of blocklisting and allowlisting in our system.

Allowlisting/Blocklisting

This guide provides an overview of the anomaly detection system, anomaly alerts and dashboard, including how they work and how to use them.

Anomaly Detection

Sardine offers various ways to identify the device. This page describes the definitions and guidance for key device identifiers used by Sardine.

Device Id, Fingerprint and Account Device Id

Comprehensive guide on integrating and utilizing machine learning models within your workflows.

Machine Learning Guide

Refer to the [overview](/guides/integration/developerResources/authentication#api-authentication) for API URL and Authentication. Check all the *reason codes* returned in signals [here](/guides/integration/developerResources/reasonCodes#reason-codes). Use the top level field called as level in the response to make your risk decisioning and use other response fields to understand the reasons for the risk level.

<h3>Products</h3>

| Use Case | Description |How| Checkpoint(s) |
|--------|---------|------------|---------|
|KYC|SSN Verification with Synthetic ID detection | Pass taxId in the request. If you want to do KYC SSN verification, customers id, taxid, name, dob and address are required. Please refer to the KYC (SSN Verification) example on RHS.| `customer` |
|KYC|Sanctions Screening & Monitoring (PEP, Sanction, AdverseMedia) | Pass Name and Country (DOB is optional but reduces false positives) after this is enabled by Sardine. As seen in the example you can pass Place of birth using personalInfo Onboarding. Please refer to the KYC (Sanctions) example on RHS.| `customer` |
|Payment Fraud|Card Fraud|Pass transaction.paymentMethod.type = "card" for transaction.amount > 0. Please refer to the Payment Fraud (Card) example on RHS.| `customer` + `payment` |
|Payment Fraud|Bank Fraud| Pass transaction.paymentMethod.type = "bank" for transaction.amount > 0. Please refer to the Payment Fraud (Bank) example on RHS.| `customer` + `ach` |
|Anti-Money Laundering/Transaction Monitoring| AML Foundational - Fiat and Crypto (BYO data)|For crypto Transaction Monitoring (TM), pass: crypto address in the address field. For Fiat TM, pass: transaction object. Please refer to the AML (Fiat & Crypto) example on RHS.| `aml` |
|Anti-Money Laundering/Transaction Monitoring|AML Crypto with Analytics| For crypto address analytics, the "Crypto Analytics" flag must be enabled by Sardine to enable blockchain monitoring. Please ensure to talk to your Integration Manager about enabling this. Please refer to the AML (Crypto) example on RHS.| `aml` |

<h3>Typical Integration Issues</h3>
<ol>
  <li>
    Different sessionKey and/or userIdHash (customer.id) values are used across the Device SDK and Customer API; they need to be the same values, i.e.:
    <ul>
      <li>Front End Device SDK *sessionKey* must correspond to the Back End Customer API's *sessionKey* value</li>
      <li>Front End Device SDK *userIdHash* must correspond to the Back End Customer API's *customer.id* value</li>
    </ul>
  </li>
  <li> Country/Region/Phone number is not passed in ISO format. e.g. phone number has +1 missing for US.</li>
  <li> Some data is not passed, despite it being available to the merchant to easily pass, e.g., Country or createdAtMillis or Address line 1 is missing.</li>
  <li> OrderNumber is not passed in the transaction.id field and instead sessionKey is passed.</li>
</ol>

*Important Customers API Checkpoints Behavior*
<br/>
Please refer to [checkpoints](/guides/integration/developerResources/checkpoints#checkpoints) for recommended use cases, descriptions and prerequisites.
<ol>
  <li>When calling the customers API, if no checkpoint is specified, then the checkpoint defaults to "customer"</li>
  <li>When the "customer" checkpoint is invoked, the "device" checkpoint is also automatically applied, which determines the risk level of the device being used. The risk level determined by the devices checkpoint will only impact the device risk level (device.level) response field</li>
  <li>
    When calling the customers API, if a checkpoint is specified, then only that checkpoint will be executed
    <ul>
      <li>e.g., if "aml" is called, only "aml" would be called</li>
      <li>If the merchant wants "customer" to be run, then they would *need* to specify both "customer" and "aml"</li>
    </ul>
  </li>
  <li>
    When calling the customers API, regardless of what checkpoints are specified (i.e., regardless of the two items above), the "device" checkpoint is always called <b>if either:</b>
    <ul>
      <li>The sessionKey matches an existing sessionKey whose device data was sent to Sardine via SDK, *or*</li>
      <li>The device.id that is sent matches an existing Sardine device.id</li>
    </ul>
  </li>
</ol>

<h3>Important Customers API Notes</h3>
<br/>
<ol>
  <li>
    Calling the Customers API
    <ul>
      <li>When calling the customers API multiple times, you will need to pass all the customer-level information in the top-level customer object the first time (this is intuitive)</li>
      <li>For subsequent API calls for that same customer, you don't need to (but you can) re-pass data, e.g., customer.firstName, customer.lastName, etc. Only the customer.id will need to be passed. If you don't re-pass this data to us, Sardine will use the existing name, email, phone, address, and SSN that exist in our records from the most recent customers API request</li>
      <li>*NOTE* this does not apply to advanced fields like personalInfo and custom fields; for such fields, merchants need to always pass these fields if they want to use them in rules.</li>
    </ul>
  </li>
  <li>
    Passing customer-level info
    <ul>
      <li>Use the <b>top-level customer object</b> to send master customer data, e.g., firstName, lastName, etc.</li>
      <li>*Do NOT use customer.personalInfo* unless explicitly discussed with Sardine for your use-case</li>
      <li>customer.personalInfo is used only if you perform verification(s) via a non-Sardine third-party provider.</li>
    </ul>
  </li>
  <li>
    Retry mechanism
    <ul>
      <li>As a best practice, we'd recommend you implement a retry mechanism as detailed [here](/guides/integration/developerResources/ResponseandRetry#retry-mechanism)</li>
    </ul>
  </li>
</ol>

Please *review* the JSON data with Sardine during development, before deploying this API in production.
There may be some *undocumented* fields in our API response. Please ignore them as they may be present for backward compatibility or may be in beta.

Evaluate customer session/transaction Risk

In order to ensure that our customers can adhere to end-user data deletion request mandated by global privacy laws such as GDPR and CCPA, we have built a simple and easy-to-use API endpoint that allows you to programmatically submit requests to delete all data for a set of known customers ID.

Delete customer information

This API allows merchants to query created business entities within the Sardine platform for basic Secretary of State verification for business entities in the United States.

Sardine recommends an <b>exponential backoff with 15 seconds</b> for polling of this endpoint after a new business entity has been submitted.

Sardine will be updating this specification in the future to support a variety of verification, screening, and enrichment types, which may require us to introduce new fields.

Get info from a business

This business API allows the merchants to verify new U.S businesses for compliance and sanction screening.

This API allows merchants to create business entities within the Sardine platform. Merchants can then perform business verification, screening, and enrichment requests for those entities.

The following request provides the required fields for basic Secretary of State verification for business entities in the United States and sanction screening. The `config` object is used to determine which enrichments should be run.

Adding a new business

Use this endpoint to update the status, name, website, taxId, or address of an existing business

Updating an existing business

Monitoring alerts for business entities

Please refer to [API Authentication](/guides/integration/developerResources/authentication) for API URL and authentication. 

This endpoint should only be used for cases where latency is critical and only the device data is required. For non-latency critical cases, please use the customers API endpoint.

There may be some *undocumented* fields in our API response. Please ignore them as they may be present for backward compatibility or it may be in beta version.

Get device information

Please refer to [API Authentication](/guides/integration/developerResources/authentication) for API URL and authentication.

This API endpoint can be used for real-time transaction approval decisions.

Note you must call [/v1/customers API](/guides/api-reference/customer/evaluate-customer-sessiontransaction-risk) at least once prior to calling this API with customer information so Sardine can pre-compute customer-level risk information and can correlate the `cardId` (/v1/issuing/risks) to the `transaction.paymentMethod.card.hash` (/v1/customers) that is sent in this API request.

Sardine automatically sets `issuingrisk` as the checkpoint for this API endpoint. You can review the rules applied under the `issuingrisk` checkpoint in [Sardine Dashboard](https://dashboard.sardine.ai/rules?checkpoint=issuingRisk).


Realtime risk check for credit/debit card authorization requests (for card issuers)

Use this endpoint to send Sardine the processor token you received from Plaid for a specific account

Post Plaid processor token for accounts

Use this endpoint to request Sardine sync the Plaid data for a specific account

Post Plaid data sync request

Please refer to [API Authentication](/guides/integration/developerResources/authentication) for API URL and authentication.<br/>

<b>If you use Plaid:</b><br/>
Refer to the [Plaid+Sardine processor token integration](https://plaid.com/docs/auth/partnerships/sardine/)
<br/>


Post bank transaction data about customer for Open Banking data other than Plaid

Please refer to [API Authentication](/guides/integration/developerResources/authentication) for API URL and authentication.

This API returns list of users whose screening (sanction, PEP and adversed media) risk check result has been changed in the specified time period.

Initial you can leave the cursor empty following that you need to add the cursor to your request to get next set of results. if the results are null or empty you have no more results.

Given that Sardine performs a daily screening for OFAC Sanctions, PEP, and Adverse Media, we would recommend you use this API daily to stay up-to-date.

This same functionality is also available without using the API and utilizing the SANCTION_UPDATE checkpoint. Please consult with your Integration Manager on how to set this rule up in the checkpoint so that daily screening and case creation automatically occurs within the Sardine dashboard.

Get updated screening (sanction, PEP and adverse media) information

This endpoint deletes monitoring data for the specified customer ID or business tracking ID.

Remove monitoring for a specific customer or business

Please refer to [API Authentication](/guides/integration/developerResources/authentication) for API URL and authentication.

Document verification token to be used in native SDKs

Please refer to [API Authentication](/guides/integration/developerResources/authentication) for API URL and authentication.

**Note**: If user not completed KYC and retrying the process please use same link until the expires_in time.


Document verification using web link

Get result of identity document verification

Please refer to [API Authentication](/guides/integration/developerResources/authentication) for API URL and authentication.


Retrieve images collected during document verification

This API is used to find if a specific blocklist exists.

Find a specific BlockList

This API is used to expire a specific blocklist if it exists.

Make a specific BlockList expire

This API gets all the blocklisted elements. But its paginated and can only retrieve a max of 500 records a time.

About Sardine

Getting Started

Types of Risk

Common Risk Problems