Intro to Spec Sheets
Last updated
Last updated
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 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:
Demographic | Description |
Under-Banked | The end users historically have had limited-to-no access to financial products. |
Banked | The end users historically have been moderately banked. So they've had access to deposit accounts, but not low APR loans, for example. |
Well-Banked | 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 the information we need to help underwrite you as a platform. This information also helps us determine what kind of payment limits we should be offering in the first iteration of your product.
This section helps break down, in Synapse terms, exactly what product you are looking to offer. The diagram above illustrates 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 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.
The section further describes each product and feature that the platform will be utilizing.
Currently, we support the following account types:
Account Type | Description |
Individuals | End users will be individuals |
Businesses | End users will be business entities |
Joint Accounts | 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 the 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 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 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.
In this section, we ask that the platform articulates its KYC and Risk Strategy (see: Intro to Risk). This is benefical as it helps reduce the risk that accompanies offering a financial product.
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.
This section goes over the basic terms of the loan. The max amount, APR, and payment schedule.
In this section, we ask that the platform articulate its underwriting policy and strategy (see: Intro to Risk) for issuing loans. Providing an underwriting policy is an important part of providing access to credit responsibily as it 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 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.
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.
