Transfers Overview

Each flow of funds detailed in this guide has unique status workflows that are important to understand to properly track and reconcile payments and manage risk.

​

Transfer Statuses

​

Flows of Funds

​

Account-to-Account (A2A)

Account-to-Account transfers, or “dual-leg” transfers, are easily processed by including both a source and destination in the transfer request. Account-to-Account transfers consist of two separate transactions:

1. The first transaction is an ACH debit to pull funds from the source into your Orum balance at Orum’s originating bank.
2. Once the funds from the first transaction have settled, the second transaction is a credit to push funds to the specified destination. The credit payment rail will be dependent on the instrument of the destination (bank account), the speed parameter chosen in the request, and the receiving accounts rail eligibility.

A2A Flow

You can also do A2A transfers through subledgers by specifying the subledger ID in the A2A transfer request. Funds from the first leg will settle into the subledger and the second leg will pull from the balance of the subledger. Any returns will also be debited or credited to the subledger in the case of a debit or credit failure.

Subledger Flow

A2A Scenarios

It is very important to note that there is risk of returns/chargebacks for both legs of an A2A transfer and each return scenario has implications on how a failure needs to be addressed. 

The diagram below shows the transfer status workflow for an Account-to-Account transfer. When there is a transfer failure, the responses will specify if the failure was at the source or destination. The following section will detail the responses you can expect via webhook, what you will see in Monitor, and explain what happens to the funds.

Transfer Completes With No Failures

In a normal A2A transfer flow when there are no returns on either leg, the transfer request will go from a  ‘created’ to ‘pending’ status and remain in that status for the first leg while funds are pulled onto the platform from the source account. The amount of the transfer will be in your pending balance.

Once the hold time on the debit is met and the debit successfully settles into your available balance, the credit leg is submitted for processing and the transfer moves to a ‘completed’ state. This signals that both legs have been processed successfully and the estimated funds delivery date tells you when funds should post in the destination account.

Debit Return (Source Failure) Before Transfer Completion

If the debit leg fails due to a return prior to settling, the funds in your pending balances will be removed and the credit leg of the transfer will be automatically cancelled. The webhook response will update the status of the transfer to ‘failed” and the status_reason will specify that the failure occurred on the source account.

Debit Return (Source Failure) After Transfer Completes

ACH debits always hold some level of risk and in some cases, the debit leg of an A2A transfer can fail after the credit has been processed and the transfer was already in a ‘completed’ state. This can happen for a number of reasons:

• Tardy returns that happen outside of Nacha’s two business day return window
• Configuration for accelerated debit hold times of less than two days given that credits are processed before the Receiving Depository Financial Institution (RDFI) is required to send returns back. 
• Unauthorized returns like an R10 that can happen days or even weeks later

When you see an A2A transaction change status from ‘completed’ to ‘failed’ and the failure is from the source account, you know that the debit leg returned after the credit has already been processed.

To solve this issue and avoid disruption to other transaction activity:

• Keep a pre-funded balance on the platform to absorb these loss causing transactions so that you always have a sufficient available balance. 
• Troubleshoot the cause of the return with your customer and submit a new request to debit their account using a single leg debit. Provide the source details and leave the destination blank. A successful retry will bring your balance back to neutral. 
• If you have a negative balance, you can top-up your balance back to zero.

Credit Return (Destination Failure) After Transfer Completes

While not as common, credit transfers do return. This is usually due to admin ACH returns (R02, R03, R04) or sometimes a real time payment will fail due to the recipient bank not being online or other technical issues. 

Any time there is a failure with the destination account, funds will be automatically added back to your available balance and you will see this in your reconciliation reporting. In an A2A transfer it is important to note that you can take two actions:

• Send a new credit transfer to the destination over a different rail or after updating the account details if they were inaccurate
• Send a new credit transfer to the source to return the funds back to the sender.

​

Payouts

Payouts or credit/push transactions using your Orum available balance are processed by sending a transfer request with only a destination and leaving the source blank or designating a subledger as the source. 

Credit transactions require an available enterprise or subledger balance that is equal to our greater than the amount of the transaction(s). If the balance is insufficient you will receive an insufficient funds error.  

Below are visual representations of Payouts from an enterprise balance and a subledger balance.

Credit transactions are far simpler than A2A and Debit transfers. As with any payment, credit transactions can return for various reasons. This is usually due to admin ACH returns (R02, R03, R04) or there are times a realtime payment will fail due to the recipient bank (RDFI) not being online due to a network outage or planned maintenance.

Card push transactions may fail due to lack of push functionality or restrictions imposed by the issuing bank. Any time there is a failure with the destination account/card, funds will be automatically added back to your enterprise or subledger balance and this will be mirrored in your reconciliation reporting.

For RTP, FedNow, or Card transactions, this will happen in real time. For ACH, funds will be credited when the return is received (generally 1-2 business days). When a Payout fails you can try a few things to troubleshoot:

• Send a credit transfer to the destination over a different rail. This generally means downgrading from a speed of “asap” and using “same_day” or “standard” so that the payment is processed by ACH instead of RTP/FedNow. 

  Card payments always use a speed of “asap” and failures are generally due to a lack of push functionality or restrictions by the issuing bank. 

• Reach out to the user to confirm account/card details to see if they were inaccurate and send a new credit transfer after updating the information.

The standard status workflow for a credit transfer is detailed in the diagram below.

​

Deposits

Deposits, or debit/pull transactions used to pull money into your Orum balance, are processed by sending a transfer request with only a source and leaving the destination blank or by specifying a subledger as the destination. 

Below are visual representations of Deposits to an enterprise balance and a subledger balance: 

Debits do not immediately settle into your available balance. Depending on the payment rail used and your hold time configuration, these funds will remain in your pending balance until hold times are met and funds are settled.

It is very important to note that there is risk of returns/chargebacks with all debit/pull transactions. The following section will detail the responses you can expect via webhook, what you will see in Monitor, and explain what happens to the funds.

Transfer Completes With No Failures

In a normal Debit/Pull transfer flow when there are no returns or chargebacks, the transfer status will go from ‘created’ to ‘pending’ to ‘completed’, signifying that the transaction was successfully submitted to the payment network of the rail being used. 

The amount of the transfer will be credited to your pending balance. Once the hold time on the debit is met it will move to a ‘settled’ status and funds will move from the pending to available enterprise or subledger balance.

Debit Return (Source Failure) Before Transfer Completes

If the debit fails due to a return prior to settling, the funds in your pending balance will be removed. The webhook response will update the status of the transfer to ‘failed” and the status_reason will include Orum reason codes/messages and network codes/messages so that you know the cause and type of return. This information is also available in Monitor by clicking on a transfer to open the transfer details page.

Debit Return (Source Failure) After Transfer Settles

ACH debits and Card Pull transactions always hold some level of risk and in some cases, the debit can fail after it has settled. This can happen for a number of reasons and it is important to familiarize yourself with the payment networks’ rules on returns and chargebacks. 

A few common failure examples are listed below:

• Tardy returns that happen outside of Nacha’s two business day return window
• Configuration for accelerated debit hold times of less than two days given that credits are processed before the RDFI is required to send returns back. 
• Unauthorized ACH returns like an R10 and card chargebacks due to consumer disputes, both which can happen days and weeks after a transaction is processed.

When you see a debit/pull transaction change status from ‘settled’ to ‘failed’, you know that the debit leg returned after funds were made available to you. If those funds were used for a payout and are no longer in your Orum available balance, this can cause negative enterprise/subledger balances and potentially create a loss causing event. It is important to know what you can do to solve this issue and recoup funds or avoid disruption to your other transaction activity:

• You can keep a pre-funded balance on the platform to absorb these loss causing transactions so that you always have a sufficient available balance. 
• You can troubleshoot the cause of the return with your customer and submit a new request to debit their account/card. A successful retry will bring your balance back to neutral. 
• If you have a negative balance, you can Top Up your balance back to zero.

The standard status workflows for a debit/pull transfer is detailed in the diagram below.