Instant payments at Cross River

Cross River is proud to offer a domestic Instant Payments product. Instant payments allow individuals and businesses to transmit funds that clear and settle within seconds between US DDAs at different US-based financial institutions. :

  • The Clearing House provides instant payments using its RTP® system. All federally insured U.S. depository institutions participating in the RTP network can send payments from and receive payments to their accounts 24/7.


Payment flow


  • Any US-based bank can join the instant payments network to send domestic transactions.


    Both sending and receiving banks must be part of the instant payments  network to send a payment over that network. Each participating bank is registered by their routing number(s), which is used to disclose the eligibility of the bank to receive various payment or non-payment messages.

  • Instant payments transactionsClosed An individual transaction processed by the RTP system, consisting of a request message followed by a response message. clear and settle within seconds.

  • There are no transaction reversals or automatic returns in instant payments. Should you need to ask for your money back, you must request a Return of Funds from the bank that you sent the payment to.

  • Any explicit limitation on the use cases that can be used for instant payments are defined by the specific network.

  • TCH has implemented a $1,000,000/transaction limit. Implementation limits vary for each Cross River partner and are subject to review.

    For example, a Cross River partner may only be approved for instant payments transactions under $10,000.

  • Cross River does not impose a receive limit lower than the maximum receive limit, i.e., $1,000,000 for TCH.

  • We support webhooks and extended data in the transaction so the receiver can see the sending account in the transaction details.

How instant payments work

Credit transfers

Instant payments transfer money between banks in real time via an instant payments network. A credit transfer is the specific message in the instant payments network used to transfer money between banks in real time (also referred to as pacs.008). The debtor is the account owner who sends the credit transfer, and the creditor is the account owner who receives the credit transfer. The debtor FI is the bank where the credit transfer comes from, and the creditor FI is the bank where the credit transfer goes. This is the same thing as a push payment. One party (debtor) sends funds to another party (creditor).

There is no pull payment on instant payments networks. One party cannot debit (take) funds from another party's bank account.

Instant payments transactions and requests are made by messagesClosed A complete transmission of an instruction or of a response from one FI to another FI through the RTP system. A message consists of two legs. sent between the debtor, creditor, their respective financial institutions, and the instant payments network.





Credit transfer message-level flow

Originating instant payments using COS

At a minimum, a credit transfer via API call must include the account number funding the transfer, the transfer amount, and the creditor account number and routing number at the receiving bank.

Instant payment use cases

Transfer funds with instantpayments for a variety of use cases.

Business to Business use cases

  • Supplier payments – A small business can pay an urgent invoice to receive goods or services

Business to Consumer use cases

Consumer to Business use cases

  • Bill payments

  • E-commerce payments – Pay online retailers or service providers.

  • Day trading – Day traders can send immediate transfers to their investment account to take advantage of the most recent market swing.

  • A homeowner can pay for general services around the house, such as cleaning help or child care.

Ultimate Debtors and Creditors

An ultimate debtor and an ultimate creditor are entities that are not part of the instant payments credit transferClosed Transfer funds from a debtor to a creditor between FIs via the RTP Network. Credit transfers can be: Push payment CR account holders can push funds via credit transfer to another RTP recipient’s account at an external bank. Credit transfers can be originated from both deposit accounts (DDAs) and directly from a subledger. Push payments are an example of an outbound RTP. Once funds are in a payee account, the transaction is final. The payer will not be able to revoke or recall a payment once it has been submitted to the RTP system. Receive payment CRB account holders can receive funds via credit transfer from an external RTP payer account. Credit transfers can be received in deposit accounts (DDAs) and their associated sub ledgers. Receiving payments is an example of an inbound RTP. The receiving participant is generally required to accept all payments and to make funds available immediately. There are certain limited exceptions. For example, a receiving participant FI can reject a payment (if the receiving account was closed), or accept a payment without posting (if the receiving account is frozen). but have some connection the transfer, and are identified for regulatory, compliance, or remittance purposes. Use an ultimate debtor or creditor whenever one party sends or receives payment for another party. Include an ultimate debtor or creditor to make clear to the receiving bank who the exact originator or recipient of the funds is.​ ​ Use of an ultimate debtor or creditor makes it much easier and more efficient to process transactions within the financial system.

When using either an ultimate debtor or creditor, the corresponding debtor or creditor account must be a business account.

You are not required to include any address attributes for the ultimate debtor or creditor. However, If you provide any part of the address you must also include all of these address attributes: addressStreetName, addressCity, addressState, addressPostalCode, and addressCountry.


Implementation Requirements at Cross River

Meet these requirements to implement instant payments at CR.

Technical requirements

You must be able to integrate with the instant payments API (RTP module). See the Instant Payments API section for examples of common API calls.

Risk/compliance requirements

These requirements apply to all instant payments transactionsClosed An individual transaction processed by the RTP system, consisting of a request message followed by a response message.s at CR:

Due diligence (DD) requirements

Depending on the type of business, there may be different additional requirements on customers and partners. All these requirements are included in the due diligence process, ensuring that the customer and partner clears all regulatory requirements and CR requirements.

DD requirements in detail

Instant payments queueing

CR queues (lines up) instant payments when a payment can't be sent because of some technical issue, so that the payment will be sent when the issues is solved, or until the payment is canceled.

In the instant payments network, participating banks must establish a connection to send and receive instant payments. From time to time, each participating bank will be unavailable to transact, either due to routine maintenance or to unknown technical issues that are resolvable with time. If an instant payment is sent to a participating bank that is not available, the payment will be rejected.

Cross River has created a user experience for partners to submit instant payments to participating banks when they are unavailable, and instead of the payment being rejected, CR will queue the payment until the receiving institution is online and then automatically originate the payment.

How it works

How Long Can a Payment Remain Queued?

All payments have a default queue expiration of 3 days. If a payment queue expiration time is reached, CR cancels the payment and you receive a Rtp.Payment.Canceled webhook event.

Can I set my own queue expiration date for a payment?

Yes. When submitting your payment request, include queuedPaymentExpiresAt, which is a DateTime type attribute and should be entered as such. The time should be US Eastern Standard Time. Below is a sample request – the additional field is in row 17.

Sample payment request with queueing
POST /v1/payments
"accountNumber": "2553179843",
"amount": 15000,
"creditor": {
"routingNumber": "011000138",
"accountNumber": "456789000",
"name": "Cleveland Brown",
"addressStreetName": "Spooner St",
"addressBuildingNumber": "34",
"addressCity": "Quahog",
"addressState": "RI",
"addressPostalCode": "00093",
"addressCountry": "US"
"addressCountry": "US"
"queuedPaymentExpiresAt": "2023-02-19T08:22:17.512Z"
  • queuedPaymentExpiresAt is an optional attribute.

  • If not populated, the default is 3 days from when the payment was sent.

  • The value entered must be a future date/time.

What if I don’t want to wait for queue expiration to be reached?

You can cancel a queued payment via the API: /v1/payments/{paymentId}/cancel.

How to test in Sandbox

Business reference information