# Realtime Returns

Column allows you to return incoming Realtime transfers if you receive a transfer in error. You can use our [Realtime Return API](/api/realtime-transfer/return-an-incoming-realtime-transfer) to initiate a new outgoing Realtime transfer to send funds back to the originating financial institution that sent the transfer.

When you return an incoming Realtime transfer, the status of the original transfer is not changed and the return transfer follows its own lifecycle as if it were an ordinary outgoing Realtime transfer. See Realtime [Notifications and States](/realtime/notifications-and-states) for more information.

### Return Reasons

You can return an incoming Realtime transfer at any time after receipt. We currently only allow incoming Realtime returns for the following reasons:

- The beneficiary account number is invalid
- The beneficiary information in the Realtime transfer does not match the corresponding information on the account
- The beneficiary is refusing the Realtime transfer
- The beneficiary is reversing the Realtime transfer as per the sender's request

If there is an additional reason you are interested in supporting, please email us at <developers@column.com>.

### Linking the Original Transfer and Reversal Transfer

The `return_pair_transfer_id` field of the `realtime_transfer` object is used to link the original transfer and the reversal transfer as:

```jsx
original_transfer.return_pair_transfer_id = reversal_transfer.id;
reversal_transfer.return_pair_transfer_id = original_transfer.id;
```

The `original_transfer.return_pair_transfer_id` is finalized once the `return_transfer.status` is `completed` and no other reversals on `original_transfer` will be permitted. Further, another reversal cannot be initiated on `original_transfer` while `return_transfer` is in progress. A new reversal can only be initiated if and when `return_transfer.status` becomes `rejected`.

### Return Requests on Incoming Transfers

It's possible Column receives a return request from the Realtime transfer originator on an incoming transfer. Column exposes Realtime return requests to you via API so that you may accept or reject a return request.

You'll receive a return request with event `realtime.incoming_return_request.pending` when Column receives the return request. You may then [accept](/api/realtime-transfer/accept-realtime-return-request) or [reject]({{realtime.reject-return}}) the request. If you accept a request, Column will create a new outgoing transfer linked to the original incoming transfer.

When rejecting a Realtime Return Request, you can provide a reason to explain why the return request is being rejected. The following reasons are supported:

- `beneficiary_account_closed` - Account is closed
- `non_sufficient_funds` - Amount of funds available to cover specified message amount is insufficient
- `funds_already_returned` - Already returned
- `rejected_by_beneficiary` - Rejected by the beneficiary
- `legal_decision` - Request rejected due to regulatory or legal rules
- `no_response_from_beneficiary` - Return request rejected due to no response from the beneficiary

Additional considerations for incoming Realtime transfer return requests:

- You can provide a comment to explain why the return request is being rejected
- You may receive more than one incoming Realtime return request for a single Realtime transfer
- You may only respond to one Realtime transfer return request per Realtime transfer, regardless of how many requests were received

### Return Requests on Outgoing Transfers

We offer the ability for you to initiate an outgoing return request on a Realtime transfer previously sent by you. When you initiate an outgoing return request for a Realtime transfer, you must specify a reason for the return request. We currently only allow outgoing Realtime return requests for the following reasons:

- `incorrect_beneficiary_account` - Account number is invalid or has been closed
- `incorrect_amount` - Amount is not the amount agreed or expected
- `requested_by_originator` - Cancellation requested by the Debtor
- `duplicate` - Payment is a duplicate of another payment
- `fraud` - Cancellation requested following a transaction that was originated fraudulently
- `tech` - Cancellation requested following technical problems resulting in an erroneous transaction
- `payment_not_justified` - Payment is not justified (missing critical information)

Additional considerations for outgoing Realtime transfer return requests:

- The receiving financial institution may or may not accept the Realtime return request
- Realtime transfer return requests that are neither accepted nor rejected will remain in the `pending` status indefinitely
- You may only create one Realtime return request per Realtime transfer