Not a Customer yet?

Already a Customer?

This is an overview of our implementation process. We will share a more detailed timeline as part of your Implementation Guide.

General Implementation

Phase 1: Setup

ETA: 1-2 Weeks

Create Account & Setup Billing Setup your account and billing to kick off your implementation.

Submit Due Diligence Please submit this as soon as possible to prevent delays! We must complete due diligence on your company and beneficial owners prior to receiving bank approval.

Kickoff Call During the kickoff call, we will go over:

1. Your Implementation Timeline

2. Your Spec Sheet (detailing your product and any relevant controls)

3. Your API Guide

4. Best Practices (weekly calls, issue tracker, communication channels, etc)

Program Sandbox Controls You will receive a custom test environment ("sandbox") that matches the controls outlined on your Spec Sheet, allowing you to test in an environment that closely mirrors what you should expect in production.

Phase 2: Sandbox Testing

ETA: 2-6 Weeks

Third Party Partner Setup Synapse will work with you to receive necessary approvals and setups from third party partners. These can be done in parallel with other steps and includes:

• Physical Card Setup with Card Printers

• Card Acquiring with Networks

• Mobile Wallet Setup with Networks and Partners

• Account Aggregation with Banks

Compliance Review Synapse will request a number of documents, screenshots and acknowledgments to ensure the necessary compliance disclosures and marketing components are in place.

Fund Reserve Account Your reserve is used to cover potential losses. The initial funding amount is agreed upon during the Spec Sheet process.

Sign Beta Acknowledgement While in Beta, we ask that you clearly disclose to your users that your product is still in Beta. This is helpful if there are regulatory inquiries while you are in Beta.

Receive Bank Approval - Provisional Our partner bank(s) review your due diligence once it is submitted to grant provisional beta approval.

Program Production Controls - with Beta Cap Your production environment allows you to test real users and real transactions. Please note that we cap the number of users while you are finishing up your Beta testing.

Phase 3: Beta Testing

ETA: 2 Weeks

Receive Bank Approval Prior to going fully live, we will [again] submit your updated documentation, along with your completed reviews, to our partner bank(s).

Remove Cap on Users Once we receive full approval, we will remove the cap on the number of users that you can onboard.

Phase 4: Fully Live

Go-Live Kickoff Call Synapse will close out any remaining items from your implementation and walk you through what to expect now that you are live!

Model Validation After you have two weeks of data and some minimum usage, Synapse will review your users' activity. This allows us to catch potential concerns before you roll out your product at scale.

Ongoing UDAAP Marketing Reviews Prior to new Marketing roll-outs, please provide all materials to Synapse for review.

Physical Card Timeline

Synapse partners with multiple card vendors to support your physical card needs.

We will facilitate a direct line of communication between you and any of our vendors so you can fully leverage their expertise.

Timelines are ultimately dependent on the vendor. However, cards generally fall into two categories:

• Print-on-Demand Cards Timeline: 6-8 Weeks

  Print-on-Demand cards are plastic cards with basic customization options. Opting for a Print-on-Demand card is the fastest option to get something to market since it does not require long lead times to print, nor does it require purchasing card inventory in advance. However, these cards have limited options for materials, finishes, and other customizations.

  Standard Card Package:

  • Card (Plastic; Glossy Finish)

  • Generic White Envelope (Optional Black/White Logo in Address field)

  • Carrier (Letter or 5x7 Paper Card to affix debit/credit card onto)

  • Activation Label (Sticker affixed to Card) - OPTIONAL

  • Inserts - OPTIONAL

• Custom Inventory Cards Timeline: Dependent on level of customization Inventory Cards allow for additional customizations of materials and finishes beyond what a standard Print-on-Demand card supports. Because these cards are highly customized, they require the purchase of inventory upfront and additional lead times. Exact lead times are subject to the printer’s printing schedule upon finalizing art.

We are RESTful

Synapse has built a RESTful JSON API for you. Which means, we use:

• POST to create a document

• PATCH to update it

• GET to query one or more documents

• DELETE to cancel or delete a document (Subtext: nothing gets deleted. It is either unindexed in case of a user or a bank account or it's canceled in case of a transaction)

To make things easier, all GET calls that get multiple documents support pagination and since our primary database is mongoDB (that's why we call everything documents), it also supports mongo filters. Example call for retrieving LOCKED users, page 2 with max 10 documents:

GET /users?page=2&limit=10&filter={"permission":"LOCKED"}

We use Headers

Mostly all requests (with some minor exceptions) require various kinds of headers. Here are some examples:

Not all headers are needed for all API calls. Some require client-level authentication while some require user-level authentication. More on this later, but a good rule of thumb is any resource that requires actions performed by the user (open deposit account, create a transaction, etc.), require user credentials (X-SP-USER-IP) while others require client-level credentials (X-SP-GATEWAY).

Idempotent Requests

To prevent duplicate creation of users, nodes, transactions and subnets, it's important provide retry attempts with idempotency keys.

All POST calls support idempotency for safely retrying requests without accidentally performing the same operation twice. For example, if a request to create a transaction fails due to a network connectivity error, you can retry the request with the same idempotency key to guarantee that only a single charge is created.

Notes to keep in mind when making idempotent requests:

• Idempotency keys expire after 24 hours.

• It is best practice to wait for a failure response from the POST call before attempting to retry the call.

We are Easy

All Synapse functionality can be broken down into the following core resources:

API Rate Limits

The following is a table of the the most common API calls and their respective rate limits. These limits cannot be increased. Please take this into account when building out your application.

Max HTTP Request Body Size

HTTP request body size is limited to 30 MB maximum.

ID Score is a probabilistic score (0-1) assigned to all users at the time of onboarding that predicts the likelihood that the identity supplied belongs to the person who is creating the account. 1 means we are 100% certain that the user is who they say they are. 0% means with 100% certainty we can say that the user is not who they say they are.

When ID Score is enabled and users have a high enough ID Score, we will only collect Base Document and SSN to onboard a consumer (individual or joint account). For users with low ID Score, we will collect Government Issued ID and Video Auth as well.

Features

At the beginning of the user onboarding process, nearly every end-user submits the following data points:

• Name

• Physical address

• Email address

• Phone number

• IP address

• Date of Birth (DOB)

We then evaluate this submitted data. For example, we will place additional scrutiny (including restrictions) on IP addresses associated with:

• Known web crawlers

• VPN proxies

• Anonymity networks (e.g. Tor)

Sometimes our model will need to account for user-submitted information that may not necessarily be an indicator of fraud. To delve deeper into a location example, a user may submit a phone number with a 415 area code (i.e. associated with the San Francisco Bay Area) while listing a current address in Los Angeles--and our model may be able to disregard the location mismatch if we can find evidence of previous San Francisco residency in their address history and we can independently verify that the user presently resides in Los Angeles. We refer to such 2nd-order logic as “derived features” of ID Score.

Note on Selection of Vendors

Three main factors are considered for determining which vendors are most useful for ID Score:

• Decisioning Tools: Ensuring that we are aligned on how the vendor determines what data to pass on to use and how they make assessments about trustworthiness.

• Coverage: Ensuring that there are no gaps or redundancies in the data.

• Sources: Ensuring that certain groups are not underrepresented or overrepresented.

After receiving the augmented data from other identity verification vendors, we use machine learning models to compare against previously-seen data patterns.

Interpreting Results

ID Score is built to be conservative with all Synapse clients in mind. Each client has the ability to adjust the score application according to their business profiles and risk preferences.

For each user, ID Score assigns a trust level (low,med or high) and an id score (0-1) after evaluating the authenticity of user input details.

While KYC programs vary platform by platform, our general guidance is the follow the following though process:

Note: A low score does not necessarily mean a user is providing false information or committing fraud, it means that we don’t have enough positive signals to assure their identity.

Implementation Guide

How to go Live

After ID Score has been added in your MSA (Master Services Agreement), we will follow the following steps:

1. We will analyze your platform’s activity and make KYC Recommendations for all three trust score values.

2. Once we agree on a KYC workflow, we will program that for you in your Sandbox environment.

3. You will then, Integrate with our API for ID Score.

4. Test both EDD and non-EDD flows for ID Score in Sandbox.

5. Once testing completes, we will enable the new workflows for you on production.

Synapse provides an easy-to-understand program overview to each platform prior to going live. This enables both parties (you and us) to be on the same page with the product and service offerings. This is also very helpful when regulators have questions about certain programs as it provides an overview of controls and flows of funds, among other details.

In this section we will be walking you through various aspects of a Spec Sheet, to ensure you have a clear understanding of how to navigate the document and the purpose it serves.

Platform Info

This section has basic company information, how you are planning to monetize your product, and who your target audience is.

Customer Demographics is broken down into the following sections:

Fundraising & Financial History

Synapse Use Case

The section further describes each product and feature that the platform will be utilizing.

Currently, we support the following account types:

KYC Program

The next section documents a platform's KYC Program, starting with document requirements and then an overview of the KYC Policy:

Document Requirements

CIP Tag 1 will be opening accounts for individuals who only need to have access to deposit accounts. For this user segment, the platform will be collecting Base Document (Name, Email, Phone, Address, DOB, and IP Address) and the user's SSN. But if the ID Score is below 0.70, the platform will also be collecting front and back of the user's Government Issued ID and Video Auth.

CIP Tag 2 is an example of the same user type but the ID Score Clip is 0.80 vs 0.70. Separating user types in this way ensures that your platform has granular control over the requirements and aligns customers to those requirements to help mitigate risk.

CIP Tag 3 is an example of a third-party payment account, the platform will only be collecting base documents on the individual/entity.

KYC Policy

Lending Program

Since in this example the platform is offering credit services, they will also have a Lending Program section in the Spec Sheet. This section has two subsections: Lending Box and Underwriting Policy.

Lending Box

This section goes over the basic terms of the loan. The max amount, APR, and payment schedule.

Underwriting Policy

Transaction Limits

This is the final section of the Spec Sheet that goes over how much a user and the platform (in aggregate), are able to process through Synapse.

Transaction Limits are a function of your operating capital and the overall fraud occurring on the platform and can be updated over time.

In this example, the platform wants to slow down settlements for ACH and RDC Pulls by 3 business days since that poses a risk of financial loss for the platform, while the rest of the transactions settle as usual.

Currently Global Cash are only able to hold USD balances, but you can onboard customers from the following countries:

• Argentina

• Australia

• Austria

• Belgium

• Brazil

• Canada

• China

• Chile

• Colombia

• Czech Republic

• Cayman Islands

• Denmark

• Finland

• France

• Germany

• Hong Kong

• India

• Ireland

• Italy

• Luxembourg

• Malaysia

• Mexico

• Netherlands

• New Zealand

• Norway

• Portugal

• Singapore

• Slovakia

• South Africa

• Spain

• Sweden

• Switzerland

• United Kingdom

• United States

• Vietnam

Key Use Cases

CMA can be used for pretty much any application that requires an embedded deposit custody. But we are seeing the following use cases most frequently:

KYC Requirements

KYC For Individuals or UBOs

KYC For Business

Please note, we are still learning more about this segment of our business and KYC requirements might evolve over time. Consider this a v1 of Non-US Business KYC.

KYC for Non-US Sole Proprietorships

For UBO's of non-US sole proprietorships, we currently support the following.

To enable, please discuss this with your growth manager.

Key Features

Getting Started with Cash Management

To spin up a Cash Account for a user, here are the steps you can follow:

The first step is to create a user account and supply all of their KYC. Once the user account has been created, grab the refresh_token from the response which is needed to issue an OAuth key for the user.

To avoid 2FA, please use the fingerprint value that you used while creating the user account. Once the OAuth key is issued, grab oauth_key which will be needed to launch deposit hub.

First please preview the cash agreement to the user, once they agree, create the cash account. Please ensure the user is able to select their custody and risk preferences.

That's it. You've successfully created a cash account for your user.

Enable Some Features

Now let's enable some features on this cash account.

Now you have an ACH-US node linked under the user profile. This means the user can fund their cash account via an external bank account or if funds are available on the cash account, the user will be able to cash out into the external bank account.

Now the user's cash account will also have an account and routing number associated with it. This can be used for direct cash (payroll, Paypal, Venmo, etc.) or direct debit (billpay, Venmo, Paypal, etc.).

Now your user has a fully functioning Deposit Hub! We would also recommend trying the following:

How it Works - Under the Hood

Unlike a Deposit Account, for the Cash Management account, Synapse Brokerage LLC is the Custodian of Funds. This enables us to keep funds at more than one bank - effectively giving your users higher than 250K FDIC Coverage (just like Multibank) or invest funds in the public markets through Money Market Funds, while the customer can still spend through their card. If funds are kept at a clearing house, they qualify for SIPC Insurance.

Other Considerations

Risk, with regard to financial products, typically falls into two primary categories: Financial Risk and Regulatory Risk. While Financial Risk leads to direct losses to your operating capital, Regulatory Risk can lead to regulatory fines or other penalties. Ultimately both categories of risk have the potential to impact your operating capital, can impact your reputation, and in extreme cases may lead to the suspension of your program altogether.

Since both categories can cause disruptive events for your business, we recommend building Financial and Regulatory risk reduction strategies. In this resource, we will break down both types of risk and provide guidance to help you address them.

Financial Risk

Following are more details on Financial Risk by types:

ACH

ACH is a one-way messaging system for payment processing. Meaning, that a transaction in ACH is assumed to have succeeded unless the receiving bank sends a failure notice.

Based on the reason for failure, the receiving bank can have up to 60 days to return a transaction, assuming they have return rights. In practice this means if you released an ACH credit in 3 business days to your user, you might still receive a return up to 57 days later. Here are the most common return reasons:

❌ = Will not lock the user or node. ✅ = Will lock the user or node.

Returns Codes

These returns are broken into three categories:

Unauthorized

These returns occur when the account holder of the ACH account informs their bank (receiving bank) that the transaction was not authorized by them. NACHA guidelines allow account holders to take up to 60 days to dispute these kinds of transactions. Return codes R07, R10, and R29 signify unauthorized returns.

Administrative

Administrative returns indicate that a transaction was returned due to administrative or account data errors. They occur within 3 business days of settlement. Return codes R02, R03, and R04 signify administrative returns.

Auto Rejection of Late ACH Returns

Auto rejection logic is in place for ACH returns that occur 60 days or greater after transaction settlement. If an ACH return request is received after 60 days of the payment settlement date, the request will not be honored.

Others

The rest of the returns are just other types of returns allowed by the ACH network. Like Administrative, these returns also occur within 3 business days of settlement.

Dishonoring a Return

Dishonoring a return is only allowed in circumstances where the return notice is late. This means, if Administrative and Other returns are coming to us after 3 business days or Unauthorized are coming after 60 days, then they can be dishonored. Otherwise, all other ACH Returns must be honored in compliance with the NACHA consumer protection guidelines.

Interchange

Unlike ACH, Interchange (more popularly know as acquiring) is capable of giving you failure notices in realtime in almost all circumstances. However, there are some scenarios, known as chargebacks that can take up to 120 days.

Based on the reason for failure, the receiving bank can have up to 120 days to fail a transaction. This means, if you released an Interchange credit instantly to your user, you might still receive a failure notice (also known as a Chargeback) up to 120 days later. Here are the most common failure reasons:

Failure Codes

Card processing presents both return and chargeback risk, which are different types of returns. An interchange return refers to a transaction being rejected by the network when it is unable to be processed for a variety of reasons. Meanwhile, chargebacks take place when a transaction occurs and settles, but a user disputes the transaction with the card issuer.

All IR failure codes are instant, except IR999. IR999 is considered an unauthorized chargeback. This means that the customer claims that they did not authorize this transaction and the user has up to 120 days to dispute interchange transactions with this failure code.

High chargeback rates can potentially lead to substantial fines by card networks, inclusion on the Terminated Merchant File for up to 5 years (a list of merchants deemed high-risk by card networks), and/or suspension from the card networks.

Chargebacks also present financial loss risk as any negative balance, resulting from chargebacks will be reconciled from the platform’s reserve account.

Disputing a Chargeback

An exception to the zero-liability policies would occur if there is evidence that the user was grossly negligent or if there was a substantial delay by the user in reporting the unauthorized transaction to its card issuance institution. Evaluating when this exception applies will be at the discretion of the card networks, platforms can submit evidence prior to evaluation of their case.

FedWire

Unlike ACH and Interchange, FedWires do not pose a financial risk to you as they are only outgoing, so there is no risk of returns and financial losses. However, it's important to note that FedWires are irreversible. So it is important to ensure that they were indeed originated by the sender and all the details submitted are accurate before originating them with us.

Originating Wires Safely

This can be done by features like enabling MFA right before originating a FedWire and showing the customer a summary page and urging them to check all the details before origination.

Failures

Though FedWires do not fail for lack of funds, they can still fail for the following reasons:

Recalling a Wire

SWIFT

SWIFT behaves similarly to FedWires. They do not pose a financial risk to you as they are only outgoing, so there is no risk of returns and financial losses. However, it's important to note that SWIFT Wires are irreversible. So it is important to ensure that they were indeed originated by the sender and all the details submitted are accurate before originating them with us.

Originating Wires Safely

This can be done by features like enabling MFA right before originating a SWIFT Wire and showing the customer a summary page and urging them to check all the details before origination.

Failures

Though SWIFT Wires do not fail for lack of funds, they can still fail for the following reasons:

Recalling a Wire

RPPS

Under the hood, RPPS is just a private ACH rail. Since all RPPS transactions are push transactions, they do not pose a financial risk. Even though RPPS do not fail for lack of funds, they can still fail for the following reasons:

Checks

Like RPPS, checks are another way for your users to pay bills. Since they are credit only, they do not pose a financial risk. Even though checks do not fail for lack of funds, they can still fail for the following reasons:

Stopping Check Payment

RDC

Like ACH, RDC is a one-way messaging system for payment processing. Meaning, that a transaction in RDC is assumed to have succeeded unless the receiving bank sends a failure notice.

Based on the reason for failure, the receiving bank can have up to 60 days to fail a transaction. This means, if you released an RDC credit in 3 business days to your user, you might still receive a failure note (also known as a Return) up to 57 days later. Here are the most common return reasons:

These returns are broken into three categories:

Unauthorized

These returns occur when the account holder of the bank account that the check belongs to informs their bank (receiving bank) that the transaction was not authorized by them or points out some other fraudulent issues with the check. RDC guidelines allow account holders to take up to 60 days to report checks as unauthorized. Return codes CHR03, CHR14, CHR17, CHR24, CHR25, and CHR26 signify unauthorized returns.

Administrative

Administrative returns indicate that a transaction was returned due to administrative or account data errors. They occur within 3 business days of settlement. Return codes CHR02, CHR03, and CHR04 signify administrative returns.

Others

The rest of the returns are other types of returns allowed by the RDC network. Like Administrative, these returns also occur within 3 business days of settlement.

RDC Forgery Fraud

If an RDC is returned due to forgery, there is no time limit against its return.

Credit Extension

For that reason, it's important for you to have a credit underwriting strategy. A good credit underwriting strategy should try to assess two things:

1. Propensity to Pay

2. Willingness to Pay

Propensity to Pay

Willingness to Pay

A good way to understand a user's willingness to pay is to measure the user's engagement with your platform. If a user finds value in your products and services, they will be more inclined to pay back the obligations through your platform over others.

Based on the above definitions, here are some examples of how you might choose to design your Credit Risk Policy, based on your overall risk appetite:

Provisional Credits

Regulatory Risk

Regulatory Risk can lead to regulatory fines. Which impacts your operating capital and in extreme cases can cause suspension of your program altogether.

Consumer Regulations

Transaction Monitoring

Synapse is responsible for transaction monitoring as part of our relationship with our partner banks. We work with our financial institutions behind the scenes to investigate and report activity as we monitor transactions across your platform. Due to the confidential nature of these reports, we are unable to share if or when we recommend a transaction or a user to be reported to FinCEN and/or other government agencies.

It is important to understand that Synapse's transaction monitoring and reporting structure does not absolve any obligations that you may have as a company independent of Synapse. For example, if your business is registered with FinCEN, and therefore has its own screening and reporting obligations, Synapse does not provide these controls as a service to you.

Credit Hub is a platform that allows you to open various types of credit accounts for individuals or businesses via an API call.

Our mission is to ensure that everyone has access to high quality financial services. So it doesn't matter if your customers are underbanked, recently immigrated, small/medium/large business owners. With Credit Hub, you can onboard customers from all walks of life.

Account Types

The different accounts we offer have different characteristics, regulatory restrictions, among other distinctions. This variety allows us to offer the best solution for each use case. Please refer to the tables below for an idea of the distinctions between our accounts.

Key Use Cases

Credit Hub can be used for pretty much any application that requires an embedded credit account. But we have seen our customers building the following use cases most frequently with this offering:

Minimum KYC Requirements

Please note, KYC requirements will differ between individuals and business users, and might further vary depending on the use case and the nature of the user. Here are minimum KYC requirements by account type and user type:

Credit Terms

Synapse's lending entity Synapse Credit LLC will be the lender for the loans. This means it will be underwriting all the lines and serving the loans to the end users or businesses.

To reduce the risk of losses for our lending entity, either the end user will be required to put 1:1 collateral in a reserve account (in case of secured loan products) or you (the platform) will be required to do so while acting as a guarantor of the loans. So in instances where loans default, the reserves will be tapped for covering the losses.

Credit Reporting

You may also choose to enable credit reporting with us. Currently, if enabled, all credit accounts of your customers will be reported by the 10th of each month for the previous calendar month. Since Synapse's lending entity Synapse Credit LLC is the lender of record, the credit report may show only Synapse Credit LLC or both Synapse Credit LLC and your name on the credit file, depending on the configuration of your program with Synapse.

Credit Decisioning

As a part of any good responsible credit model, a robust credit decisioning policy is a core part of the program. When building credit policies, please consider the following decisioning constructs:

Prerequisites

You can filter which of your users has the option to apply for a loan based on various decisioning criteria, we refer to these as prerequisites. Common examples are that the user has been in the platform ecosystem for over six months or that they are part of the platform's premium service.

Although you can propose prerequisites, they will all have to be communicated in detail and be approved by us as the lender of record. Furthermore, if you wish to make a change to your prerequisites, the change will have to be first explained in detail and approved by Synapse for the same reasons.

Base Decisioning

At a basic level a loan can be rejected based on the following criteria:

• Lending is not currently available for the user's CIP tag or user type.

• The requested amount is above the defined maximum per user loan size of your platform.

• The loan will put you over the limits of the amount (in dollar value) of loans you are allowed to issue.