Spidr Overview

Spidr is a platform that streamlines integrations for fintechs and non-fintechs by consolidating and enriching data sources for embedded finance products into a single source of truth. Spidr provides an anchor relationship with a processor/ledger while offering access to value-added services and vendors for fraud monitoring, "Know Your Customer" (KYC), "Know Your Business" (KYB), "Anti-Money Laundering" (AML), and more.

Spidr operates outside the traditional "Banking as a Service" (BaaS) model, focusing on building a robust platform designed to address the challenges faced by conventional BaaS providers. Spidr's platform enables companies of varying sizes across different industries to develop, launch, and expand embedded banking and fintech products​.

Spidr's Key Benefits

Embedded financial products have faced increased scrutiny, resulting in fewer opportunities to partner with processors and banks due to more stringent requirements. The technical complexity of implementations and the regulatory shift towards direct bank relationships makes it increasingly difficult to launch and maintain financial products.

This is where Spidr's unified platform steps in 👞

• 🏦 Gain access to proven processors and banks
  • Spidr leverages its network of processors and bank partners to connect clients with respected, tenured institutions that align with their product needs.
  • Since Spidr serves as the technology connection layer, clients maintain a direct relationship with their sponsor bank. This avoids the common pitfalls of the traditional BaaS model.
• 🕸️ Simplify integrations
  • Spidr simplifies the web of integrations needed to launch and support a new program. Spend less time juggling vendor calls and sifting through complex documentation, so you can focus on creating an exceptional product.
  • Integrate with a single API, where all data is tied to a single record, simplifying workflows and improving data accuracy.
• 💸 Enjoy unbeatable pricing and flexibility
  • Through Spidr's industry connections, our clients receive better pricing compared to direct integrations.
  • No vendor lock-in:no_good:. Clients have complete freedom to bring in their own vendors and/or choose from our partner list for KYC, fraud/AML, card embossing, etc.

Program Types & Products Supported

Spidr supports a wide range of products; the list below is not exhaustive. Almost any program requiring a processor connection can benefit from Spidr's unified platform. If you have any questions about your use case, please reach out to a Spidr contact.

📘

Note: The products below are not mutually exclusive. Your program can offer as many products as needed under Spidr.

ACH Only

With this type of product there are no virtual or physical cards, no bill payment options, no ATM or "Point of Sale" (POS) capabilities, and no check deposit acceptance. This model is typically payments-focused.

• "Business to Business" (B2B) programs may use this model for accepting payments on the user's behalf and then sending those payments to another financial institution. It may also be used to support Accounts Payable transactions.
• Consumer programs may use this model for lending activities where they disperse funds to a user. Payments to said loan would then be received via ACH.

Debit/Savings

• Debit: A “Demand Deposit Account” (DDA), commonly called a “spend” account, that is accompanied by a virtual and/or physical debit card. Funds can be credited to the account via ACH, direct deposit, debit card, check, or peer to peer transactions.
• Savings: Also called a “save” account, depending on whether interest is offered on the balance. This product can be offered on its own or as an accompanying product to another account.

Credit

Credit products typically feature a card with a defined credit limit and a monthly repayment structure.

• Unsecured Credit: An unsecured card requires no collateral or deposited funds. The credit limit is determined based on factors like FICO scores, which are used for underwriting.
• Secured Credit: Credit can also be offered through a secured card requiring a deposit and/or balance in an accompanying account used to set the defined credit limit. If payment is not received, the balance in this account will be used to satisfy the payment.
• Loans: Loans can be either secured or unsecured, but they do not involve a physical card. Funds are distributed via ACH to a linked account, where they can be accessed. Repayment is also processed via ACH or through a connected debit card.

Unified API Overview

With the basics covered, let's hop into an overview of Spidr's unified API. The goal of this section is to give you a summary of the important concepts and objects within Spidr's unified data model. At the end of this guide, you'll also see a data flow diagram that illustrates how information flows through the Spidr platform.

As mentioned above, the functionality we'll cover is offered through a single API. This means you only need one API key, one webhook endpoint, and one set of documentation (you're already here 🥳) to get started. See here for guidance on integrating with Spidr's unified API (reach out to a Spidr contact if you don't have access).

📘

Note: The information below is also accessible via the "Spidr Service Tool" (SST). More information on SST can be found here.

User Vs. Account

Before we jump into the user and account actions supported by the unified API, it's important to delineate the difference between 'user' and 'account' within the Spidr ecosystem.

Users 🧑‍🦰

• A user is an entity who has engaged with your program for onboarding. A user may or may not have completed onboarding and may or may not have an account.
• Creating a user first helps you maintain a record of all onboarding attempts and is essential for fraud prevention and KYC/KYB processes. You can use user information to run KYC and fraud checks through your own vendors or through Spidr's "Zero Touch Monitoring" (ZTM) tool (see here), and use the results to decide whether to proceed with opening an account.
• KYC/KYB must be performed on a per-user basis.
• A user record is required before an account can be created.

Accounts 🧑‍🦰:moneybag:

• An account represents a user who has completed onboarding and is associated with a financial product in your platform. The "Personally Identifiable Information" (PII) tied to a user is used to open an account.
• Working with Spidr, you'll determine what types of products you want to support. You'll then associate a product with an account upon account creation. The first account associated with a user is treated as their primary account.
• Each account is associated with a single product, but users can be associated with multiple accounts (and therefore products). For example, a user could add a secondary savings or overdraft account to complement a DDA account.
• Accounts can typically be added without requiring KYC/KYB since it's tied to the same user information.

User

The 'user' is the foundation of all records within Spidr's system. As covered above, a user record must exist before any other actions can be taken. The following actions/endpoints are supported:

Create User

The first step in building a relationship with your program is creating a user profile. This is crucial, as you can't set up a user account or request a virtual or physical card without it. After completing KYB/KYC and necessary fraud checks (via ZTM or another vendor), you can submit all required PII to Spidr to generate the user record.

Get User Info

Spidr can return all data associated with a user including their onboarding status, personal information, and any associated accounts.

Update User

You can update a user's information at any time, both before and after onboarding, to correct errors and ensure their record remains accurate and up-to-date. Any user updates are automatically propagated to all of the user's associated accounts so that everything stays in sync. See below for an example of how updating a user's info fits into the onboarding flow.

Account

Create Account

User profile created? ✅ Any necessary updates made? ✅

Now it's time to create an account. Accounts are associated with a financial product in your platform and establish the user's relationship with the underlying processor. A user can have one or more accounts. Accounts can also be linked to other accounts and can even share balances with others.

As with a user record, creating an account will generate a unique account ID that can be used across Spidr's unified platform. The establishment of of an account allows your user to use ACH, receive direct deposits, get a card, transfer money, and more depending on your product settings.

Update Account

Personal information about a user can be updated via the aforementioned user endpoint. Account-specific information like shipping address (to ship a card) and account settings (like early ACH access and transaction blocks) can be modified per your product's configuration.

Add Account

One or more secondary accounts can be added to a primary account to offer additional products supported by your program. These secondary accounts can have shared or separate balances.

Update Account Status

Spidr offers a set of simple and intuitive statuses to manage the account lifecycle. You can place a hold on an account to investigate fraud, mark an account as delinquent, or simply close it with or without refund. Through Spidr's unified platform, any downstream cards and linked accounts are automatically updated to give you peace of mind and ease the heavy lifting of keeping things in sync. 🏋️

For more information on account statuses, please refer to the Spidr integration guide here.

Get Account Info

With a single call you can easily pull all relevant account details including the balance, cards, and any other linked accounts.

Managing Disputes

Dispute management is an essential component of any card program. All dispute details can be submitted via SST. Spidr will work with the appropriate member of your team and supply updates on status/communications with all parties involved. A disputes API integration is planned for 2025.

Transactions

ACH

ACH serves as the backbone for money transfer in the US. It's used to move money from bank to bank, including from your user's external bank to their account with your program. With Spidr you can easily generate ACH transfers, return ACH credits that may seem suspicious, and even cancel an outgoing ACH before it's sent to the network.

Spidr provides access to the deposit history for your entire program or individual user accounts. This allows your team to support research and reconciliation efforts and enables your customer service team to effectively respond to inquiries.

Create Adjustment

Spidr supports the ability to create a manual adjustment (credit or debit) on a user account. Whether you are reimbursing a user for a fee or have a custom credit use case for a rewards program, Spidr has you covered.

Create Account Transfer

Spidr provides the ability to transfer funds between accounts in your program. The accounts can belong to different users or the same user (secondary accounts). Fees can also be assessed on the transaction per your product configuration.

🚧

Best Practice: Only allow these transfers between users within your program to mitigate illegal or fraudulent money movement. Your banking partner will need to approve this functionality and the limits for these transfer types.

Fees

As part of your onboarding, you'll configure your product(s) to automatically assess fees. Commonly assessed fees include card replacement fees, bill pay fees, monthly program membership fees, foreign ATM fees, or late fees for credit card payments. Fees can be assessed as flat amounts or as a percentage of the settled transaction amount (e.g. a 3% fee for international ATM withdrawals).

Spidr also gives you the ability to manually assess fees to your users' accounts for scenarios that aren't covered by your product configuration.

Get Transaction history

You can retrieve all transactions for a specific user and timespan. Spidr returns all transactions on the ledger, including backouts, denied transactions, "Address Verification Service" (AVS)-only requests, and tokenization requests.

Cards

Add Card

If you are offering a product that isn't ACH only, your users are going to need something very important. A card! 💳

Spidr supports the generation of both physical and virtual cards. You can tie a card to account creation or allow users to request one later. Spidr also supports the provisioning of mobile wallets.

📘

Best Practice: There should be a single active card per account.

Emboss Card

You’ll need to emboss cards if your card strategy includes physical cards. Your card embossing partner will create both the card and the card mailer. Card orders are sent to the embosser daily and both SST and the Spidr API will provide updates on the emboss status.

Freeze Cards

Spidr provides granular controls at both the card and account level to freeze cards or place holds on certain types of transactions. For example, you can block physical card transactions or mobile wallet transactions.

Replace Lost/Stolen Card

If your user reports their card lost or stolen you can easily request a new card be embossed. Using this endpoint will generate a new "Primary Account Number" (PAN), "Card Verification Value" (CVV), and expiry for the replacement card. If your product includes digital cards, the new digital version of the card will immediately be usable.

Reissue Card

Over time, "Europay, Mastercard, and Visa" (EMV) chips and magstripes can wear out, or a card may become damaged from regular use. When this occurs, users will likely request a replacement. You can reissue a card, providing a new one with an updated CVV and expiration date.

Set PIN

Most physical cards require a "Personal Identification Number" (PIN). While this is usually mandatory for debit cards, credit cards may also need a PIN for international transactions.

Statements

Generating Statement JSON

Regulations require that you provide users with a monthly account statement. Spidr simplifies this by supplying "JavaScript Object Notation" (JSON) statement data for each account in your program, allowing you to generate "Portable Document Format" (PDFs). These JSON statements can be retrieved on-demand.

RDFs

Reconciliation is crucial to ensure all money movement is accurately tracked. Spidr supports this by providing daily "Raw Data File" (RDF) uploads via "Secure File Transfer Protocol" (SFTP). These files include detailed extracts of the previous day’s processor activity, aiding in reconciliation, issue resolution, and informing any of your custom data stores. Some example RDF types are:

• Account Card - list of cards issued​
• Customer Master - A list of primary accounts, their balances, and customer information​
• Authorized Transactions - Authorization activity​
• Posted Transactions - Settlements, payments, adjustments, and fees​

You made it to the end! 🎉