Instant funding for Credit Builder Cards

When your consumer signs up for a Credit Builder Card, they'll have to fund the Security Deposit Account (SDA) before they can spend any money on the card. After the SDA is created, the overview steps are:

1. Consumer initiates an ACH Deposit of $100 from an external account to their SDA.
2. Consumer waits 2 or 3 business days for the ACH to clear.
3. After the ACH clears, the balance on the SDA and the credit limit of the Charge Card are both $100, and the user can start spending.

While this flow is simple, your product's adoption will improve substantially if you can allow some funds to be spent immediately after the ACH is initiated. Then, the user can go from signing up and performing KYC to being able to spend money on a real transaction in their digital wallet in a single session.

Implementing Instant Funding for CBCs is a a relatively simple technical process (described in the diagram below), and developers on Bond typically can add Instant Funding to their application in under a week.

Each step is described in detail below.

Creating and funding the Funding Account

The Funding Account is the account that will be used as the source of the instant funding. Bond's guide on Building Commercial Banking describes the steps needed to set up a deposit account for your business. If you need assistance creating this Funding Account, Bond's support teams can create this account for you.

Once this account is set up and you have its ID, there are two ways to move funds into that account:

1. (recommended) Use the GET accounts/:account_id endpoint to retrieve the Account and Routing Numbers for this account, and initiate a transfer from your commercial bank account portal.
2. Link your commercial bank account via the v0 POST accounts endpoint, and then initiate a transfer from the linked account to the Funding Account. (Note: To test Instant Funding in the sandbox, this is the only available option.)

Performing instant funding

When a user initiates an ACH to fund their account, in addition to initiating that ACH, you will also trigger an account-to-account transfer to float funds for the user to be able to spend, while the ACH is awaiting clearance.

curl --request POST \
     --url https://api.bond.tech/api/v0.1/transfers \
     --header 'content-type: application/json' \
     --header 'Authorization: YOUR-AUTHORIZATION' \
     --header 'Identity: YOUR-IDENTITY' \
     --data '
{
     "origination_account_id": "funding_account_id",
     "destination_account_id": "consumer_sda_id",
     "description": "Instant Funding",
     "amount": 2500 # amount to provide as instant funding (in this example, $25.00)
}
'

Once these funds are instantly provided, you will need to store a record that the ACH to fund the SDA has an associated Instant Funding transaction, so that when the ACH settles, you know to return funds to the Funding Account.

Returning floated funds after ACH settlement

Once the ACH is no longer pending, you'll want to return the floated funds back into the Funding Account. To do this, you will listen for webhooks on the transactions event, and filter specifically on webhook events where the transaction.transaction_id is an ID that you have made an Instant Funding transaction for.

There are two cases you'll see:

• The webhook says that the ACH is now completed. In this case, you'll return the full amount of the Instant Funding back to the Funding account, and the account will continue operating as usual.
• The webhook says that the ACH is now returned. This means that the ACH did not clear successfully (common reasons are that there were insufficient funds in the source account, the source account was closed, etc). In this case, you'll return the lesser of the instant funding amount and the current balance of the user's SDA into the Funding account.
  • For example: if a user initiates an ACH to fund their account, you trigger an instant funding to provide them $25 while the ACH is waiting to clear, the user spends $5 of the $25 on the card while the ACH is waiting to clear, and then the ACH gets returned, then assuming there have been no further deposits into the SDA, you will only be able to transfer $20 back into the Funding Account, with the $5 being losses on the program.

# upon receiving a webhook that the ACH status has changed
curl --request POST \
     --url https://api.bond.tech/api/v0.1/transfers \
     --header 'content-type: application/json' \
     --header 'Authorization: YOUR-AUTHORIZATION' \
     --header 'Identity: YOUR-IDENTITY' \
     --data '
{
     "origination_account_id": "consumer_sda_id",
     "destination_account_id": "funding_account_id",
     "description": "Returned Instant Funding Amount",
     "amount": 2500 # amount to return to the Funding Account (in this example, $25.00)
}
'

Other considerations

Recommendations to reduce risk of Instant Funding

As seen above there is some ACH return risk associated with Instant Funding. While specific recommendations will be specific to your program and user-base, there are several ways to reduce this risk:

• Perform balance checks with a service like Plaid prior to initiating ACHs. If you are using Bond's Plaid relationship, Bond performs these checks on your behalf, but if you are linking accounts manually, then you will need to do these checks to reduce the risk of transfers being returned for Insufficient Funds.
• Cap the amount that you provide as Instant Funding. Even if the user triggers an ACH for a large amount, we recommend only performing an instant funding of a fixed maximum amount (e.g. $10-$50) - the purpose of Instant Funding is to allow for 1-2 transactions on the card so that it can become top-of-wallet, not to perform a repeated real-time payments system.
• Only make Instant Funding available to existing users. To reduce the likelihood of fraud on an instant funding mechanism, we recommend using this tool for users you have some prior relationship with.

Displaying instant funding on statements

When triggering instant funding, note that the account-to-account transfers involved will show up on the consumer's SDA statements. Therefore, we recommend making the description of those transactions something that the end-user will find intuitive when they read their statement.