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.
We call this program overview a Spec Sheet. Here is an example of what a Spec Sheet looks like.
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.
This section has basic information of who you are as a company, how you are planning to monetize your product and who your targeted audience is.
Customer Demographics breakdown into the following sections:
The end users historically have had limited-to-no access to financial products.
The end users historically have been moderately banked. So they've had access to deposit accounts, but not low APR loans, for example.
The end users are well represented by mainstream Financial Products. They tend to be on the higher end of the socioeconomic ladder and have access to most mainstream financial products.
Since offering financial products pose a financial risk (see: Intro to Risk), understanding your operating capital and runway gives us much needed information to help underwrite you as a platform.
This helps determine what kinds of payment limits we should be offering in the first iteration of your product.
This section helps breakdown, in Synapse terms, exactly what product are you looking to offer with this. In this example the diagram above shows that the platform wants to issue two kinds of Deposit Hub products (Interest Carrying Deposit and Custody) and one Credit Hub product (One-Time Loan).
The platform also intends to utilize our various Payment Accounts for funding the deposit account or paying bills, while also utilizing it for making loan repayments.
Lastly, the platform will be utilizing Account Number Issuance to enable direct debit or credits in and out of the user's deposit account. While also Issuing Cards to build a debit card product on top of the deposit account and a charge card product on top of a custody account.
Then the section further extends into describing each product and feature that the platform will be utilizing.
Currently we support the following account types:
End users will be individuals.
End users will be business entities.
End users will be opening combined accounts together (E.g. families).
Third-Party Payment Accounts
No end users, user accounts will be opened for third-parties that the users need to send payments to.
This is usually done in conjunction with above account types as this is a way for your users to make payments to individuals/entities that are not a part of your platform.
The next section documents a platform's KYC Program, starting with document requirements and then an overview of the KYC Policy:
In this section, we document various users, the products and KYC info required to enable those products. For instance, in this example, the platform will be opening accounts for three user segments. So we will be differentiating them with different CIP tags (see: User Details).
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 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 so that they make sense for your customer base and help mitigate risk as appropriate.
CIP Tag 3 is an example of a third-party payment account, the platform will only be collecting base document on the individual/entity.
In this section, we will ask that the platform articulate their KYC and Risk Strategy (see: Intro to Risk). This is usually a good exercise for platforms as it helps reduct financial risk offering a financial product usually poses.
Since in this example the platform is also offering credit services, the platform will also have a Lending Program section in the spec sheet. This section has two subsections: Lending Box and Underwriting Policy.
This section goes over the basic terms of the loan. The max amount, APR, payment schedule.
In this section, we will ask that the platform articulate their underwriting policy and strategy (see: Intro to Risk) for issuing loans. This is an important part of providing access to credit as if not provided responsibility, the users can be under debt and this can become a source of financial loss for the platform.
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 us.
Transaction Limits are a function of your operating capital and overall fraud occurring on the platform and therefore can be updated overtime.
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.
In this section, you will also find information on your Sub BINs and the Card Style IDs. Card Style IDs are used when you ship a card to your users.