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

Features

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

    Note

    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.

Note

 

 

 

Credit transfer message-level flow

Find a complete list of instant payments-related documents from The Clearing House here.

Messaging terms

Role

Description

Leg

A transmission from an FI to the instant payments system or the instant payments system to an FI. Either FI may initiate an RTP instruction.

Message

A complete transmission of an instruction or of a response from one FI to another FI through the instant payments system. A message consists of two legs.

Transaction

A full round-trip consisting of an instruction message and a response messageClosed "Any status or system-based acknowledgment message sent immediately in response to a request. Messages such as the response for request for information (RRFI) and response to request for return of funds (RRRF) are initiated by the participant as an answer to an earlier request transaction and are considered new request messages rather than response messages.". All payment transactions have 5 legs (as in the example shown), including the payee FI confirmation leg.

Message-level flow

As part of the round-trip payment messaging:

  1. CR authenticates the payer, receives a payment instruction from the payer via a supported channel applicationClosed The participating FI system that the customer interacts with, responsible for the initiation or the receipt and processing of an RTP Message (such as an internet or mobile application)., and performs account and payment verification and approval. This may include, but is not limited to, checking the payer account balances, earmarking funds for the debit, and performing fraud checks. CR then creates a credit transfer message.

  2. CR sends the credit transfer message to the instant payments system. The instant payments system performs a series of formatting, process, and business rule validations before the message is routed to the payee FI.

  3. The payee FI receives the message from the instant payments system and conducts its own validations to ensure the message is correct and secure.

  4. The instant payments system awaits a response for the defined timeout period.

  5. For all validated messages, the payee FI sends the instant payments system a Message Status Report. This indicates that the credit transfer has either been accepted or rejected. The Message Status Report (pacs.002) provides a response to the credit transfer (pacs.008). The response shows whether the credit transfer was Accepted, Accepted without Posting, or Rejected. The TCH documentation explains the message statuses in detail.

  6. The instant payments system validates the response. If the response is received within the timeout period and formatted properly, it is passed along to CR.

  7. CR then informs the payer of the payment status based on the payee FI accept or reject response.

  8. In addition, the instant payments system provides a Message Status Report called a message receiver confirmation message. This is the fifth leg in the figure above. The message receiver confirmation message notifies the payee FI that the response has been received within the timeout period and the transaction has been settled. This allows the payee FI to make the payment immediately available to the receiver.

  9. The payee may optionally send a message confirming receipt of funds and providing additional information.

In addition to the payment flow outlined above, instant payments includes a number of payment-related messages (non-payment messagesClosed "A message other than a payment message or payment message response, in the format specified in the RTP technical specifications, that is transmitted between the RTP system and a participant or between participants. Non-payment messages include payment-related messages and payment-related message responses (such as payment acknowledgments). ") that enable payeesClosed The person or company that receives a payment via RTP. Also known as creditor. and payers or payee FIsClosed "The payee FI (financial institution) sending the RTP payment. Also known as the sending participant or participating FI. " and payer FIs to communicate data regarding a payment. A payment-related message may be remittance adviceClosed A payment-related message that a payer’s FI submits to the RTP system that is associated with, and that provides additional information about, an RTP payment., a payment acknowledgment, or a request for return of fundsClosed A payment-related message that a payer’s FI submits to the RTP system, for delivery to the payee’s FI, to request a return of funds that were sent to the payee..

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

As such, the bank has developed risk-based procedures to apply to partners seeking to engage in instant payments. Given the heightened risk presented by these parties, when seeking to onboard to the instant payments system, the following will be required:

  • Summary of business process/program description

  • Payment structure/visual flow of funds (i.e., narrative and diagram)

  • CR Fintech Banking Application (“Payments Application”)

  • Most recent annual audited financial statement/income statement/business tax return

    • If the entity is publicly listed (or equivalent regulated status with public information), this should be publicly available

    • This must be obtained, whether direct from the partner, or via public sources

  • Most recent 3 months of bank statements

    Note

    If the entity is publicly listed, this is not applicable. Ask instead for who their current banking relationship is with.

  • If currently processing, most recent .3. months of transactional activity (i.e., volumes) and return rates

    • If no actual activity, then obtain 6-12 months of projections

  • List of underlying Top 10 customers the partner will process for (through CR), including (1) by volume ($ value) (both credits and debits, separately); and (2) by count (# transactions) (both credits and debits, separately) – if applicable.

    • If the entity is publicly listed, this is not applicable

  • The entity has a process to implement Multi Factor Authentication (MFA) for fraud control

  • If the entity is a Payment Service Provider (PSP) as defined by The Clearing House (TCH) rules and internal CR guidance, the following requirements apply (Note: this is not applicable to all use cases in RTP - for additional questions about PSP applicability, please contact your onboarding manager or your relationship manager for assistance):

    • The entity has completed PSP Application

    • The entity has obtained a copy of their PSP Audit Report confirming PSP Compliance Criteria

      Note

      The PSP Audit Report (and recertification of the Compliance Criteria) must be updated on an annual basis.

    • Name of independent third-party auditor who conducted the PSP Audit for the PSP.

    • The entity has signed the PSP Agreement.

The above documents should be obtained as soon as possible to ensure a swift Due Diligence review. However, if the entity is newly registered as a PSP and is not yet live on the instant payments network, the PSP Audit Report and PSP Agreement can be obtained post-approval as a condition to go-live/launch. Launch will be delayed so long as the PSP Audit Report and PSP Agreement have not been obtained.

Additional specific requirements are outlined in TCH’s RTP Operating Rules and Legal and Regulatory Compliance Guide related to Payment Service Providers (PSPs). You can find these here: https://www.theclearinghouse.org/payment-systems/rtp/-/media/73118cf25e8043239672eb270cf47b9b.ashx.

Contact CR’s Legal team if you need further clarification.

  • If the entity is a bank, they must also be a participant on the instant payments network.

    • If they are a participant, escalate to Control group for assessment.

  • The entity’s relevant regulatory compliance policies/procedures:

    • Privacy Policy & Terms of Service (TOS).

    • Complaints Policy or equivalent document.

    • Dispute Resolution Policy.

    • Confirmation that Records Management Policy is in place.

    • Consumer protection controls, including:

      • EFTA and Reg E

      • UDAAP

      • Pass-Through Insurance Disclosure

  • Relevant Information Technology (IT)/Information Security (Infosec) Compliance Company Policies/Procedures:

    • Contact CR IT Compliance for their review and approval of the entity based on the internal list of Infosec-related due diligence requirements for RTP and confirmation that the review is satisfactory.

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

  1. Payment is submitted to CR via API

  • Can optionally include a queue expiration date and time in the event the payment is queued due to RDFI offline.

  • Expiration date will determine how long a payment will wait in queue for the RDFI to go back online before turning to a canceled status.

  • Expiration date will not support a time component and will only be used in the unlikely event an RDFI is offline for an extended period.

  1. If the receiving institution is offline:

  • Payment status changes to Queued.

    • You will receive an Rtp.Payment.Queued webhook

  • Once the receiving institution is back online:

    • Payment status changes to Processing.

    • Processing status indicates the payment has been sent to the RDFI and we are awaiting a response. Payment can no longer be canceled and must wait for a response from the instant payments network.

  • If payment expiration date is reached while the receiving institution is still offline:

    • The CR system cancels the payment

    • Payment status changes to Canceled.

    • The Rtp.Payment.Canceled webhook event fires.

  1. If receiving institution is online

  • Payment will flow through as normal

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.

Copy
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

To test queueing:

Register for webhook Rtp.Payment.Queued.

  1. Submit payment using any of the following creditor routing numbers:

    • 000000010

    • 000000017

    • 244084264

  1. If participant is offline, the Rtp.Payment.Queued webhook fires and the payment status goes to queued.

    • Once the participant goes online, payment resumes the normal workflow.

  1. If payment was not queued, continue to periodically submit payments until participants cycle offline.

Business reference information

Direction

Description

Inbound

Payment received from another bank

Outbound

Payment sent to another bank

Status

Description

Created

The initial status of inbound and outbound payments

Pending

Outbound - payment is being validated prior to submission to the RTP network

Inbound - payment has been received transaction is being authorized

Processing

Outbound - payment has been submitted to the instant payments network

Inbound - payment has been authorized and is waiting confirmation from the RTP Network that transaction has processed successfully

Completed*

Outbound- Payment was accepted and received by the receiving institution

Inbound- Payment has been accepted and received

For credit transfers, completed also means the payment has posted successfully

Rejected*

Inbound - payment was automatically or manually rejected
Outbound - the receiving institution or the RTP Network rejected the payment

Reason Code for the rejection can be found in Result.Code on the payment

Canceled*

An outbound payment initiated by an internal user and canceled while in a hold status. A payment may only be canceled while either in a Hold or ResearchRequired status.

Hold

The payment is currently on hold and being reviewed by the Operations Team

TimedOut*

A payment was not acknowledged within the SLA with The Clearing House

Failed*

The payment has failed due to technical reasons

Finalizing

Payment is in process of posting to an account

ResearchRequired

Response to an outbound payment was not received and manual review of the payment is required to determine if the payment should be canceled or completed

*Indicates the status is the final status for a payment

Type

Description

CreditTransfer

Payment sent by a Debtor FI to a Creditor FI

ReturnRequest

The originator of the original payment is requesting the funds be returned. This is a non-monetary transaction.

Sending a Return Request is not currently supported

ReturnResponse

Response to a Return of Funds request. This is a non-monetary transaction. The actual money movement to return funds would be done in another payment as a credit transfer.

This is a non-monetary transaction

SystemTimeout

Notification to the Creditor FI that a Credit Transfer has timed-out

This is a non-monetary transaction

RemittanceAdvice*

The ability for the Debtor to send stand alone remittance information to the Creditor and
the ability for the Creditor to send detailed invoice information to the Debtor (B2B or B2C)

This is a non-monetary transaction

RequestForInformation*

Used to request additional details related to a Credit Transfer

This is a non-monetary transaction

PaymentAck*

A Creditor (end-user) may use a Payment Acknowledgement to acknowledge a Credit Transfer has been received and applied

A Creditor FI must use a Payment Acknowledgement to confirm the funds associated with a Credit Transfer previously accepted without posting (ACWP transaction status), has posted to the Creditor’s account

This is a non-monetary transaction

RequestForInformationResponse*

Used by the sender to provide the requested additional information in the form of an amendment to the original Credit Transfer

This is a non-monetary transaction

Unknown

Payment type was not recognized

*Indicates the payment type is not currently supported

Network Platform

Description

TCH

The pacs.008 credit transfer is routed through the RTP via TCH network

FedNow

The pacs.008 credit transfer is routed through the FedNow network
<blank>

If no Network Platform is specified, CRB uses smart routing to try a network based on partner configuration and routing number availability

Code

Description

AC04

Closed Account Number

AM04

Insufficient Funds

ARDT

Already Returned

CUST

Customer Decision

LEGL

Legal Decision

NOAS

No Answer From Customer

NOOR

No Original Transaction Received

The reasonCode attribute provide the reason a message did not complete. The resultCode will be OK if the payment was successfully sent/received.

Code

Description

650

Cannot parse the message

690

Signature mismatch or verification error

BLKD

Payment has been blocked

AC02

Debtor account Is Invalid

AC03

Creditor account Is Invalid

AC04

Account closed

AC06

Account is blocked

AC07

Creditor account closed

AC10

Debtor account currency is invalid or missing

AC11

Creditor account currency is invalid or missing

AC13

Debtor account type missing or invalid

AC14

Creditor account type missing or invalid

AG01

Transaction is forbidden on this type of account

AG03

Transaction type is not supported/authorized on this account

AGNT

Incorrect Agent

AM02

Specific transaction/message amount is greater than allowed maximum

AM04

Amount of funds available to cover specified message amount is insufficient

AM09

Amount received is not the amount agreed or expected

AM11

Transaction currency is invalid or missing

AM12

Amount is invalid or missing

AM13

Transaction amount exceeds limits set by clearing system

AM14

Transaction Amount exceeds limits agreed between bank and client

BE04

Specification of creditor's address, which is required for payment, is missing / not correct

BE06

End customer specified is not known at associated Sort/National Bank Code or no longer exist in the books

BE07

Specification of debtor's address, which is required for payment, is missing / not correct

BE10

Debtor country code is missing or invalid

BE11

Creditor country code is missing or invalid

BE13

Country code of debtor’s residence is missing or Invalid

BE14

Country code of creditor's residence is missing or Invalid

BE16

Debtor identification code missing or invalid

BE17

Creditor identification code missing or invalid

DS24

Waiting time expired due to incomplete order

DT04

Future date is not supported

DUPL

Payment is a duplicate of another payment

DS0H

Signer is not allowed to sign for this account

FF02

Syntax error reason is provided as narrative information in the additional reason information

FF03

Invalid Payment Type Information

FF08

End to End Id is missing or invalid

MD07

End customer is deceased

NARR

Reason is provided as narrative information in the additional reason information

RC01

Bank identifier code specified in the message has an incorrect format

RC02

Bank Identified is invalid or missing

RC03

Debtor FI identifier is invalid or missing

RC04

Creditor FI identifier is invalid or missing

TM01

Invalid Cut Off Time

TK01

Invalid Token

TK02

Sender Token Not Found

TK03

Receiver Token Not Found

TK04

Token Expired

TK05

Token Found with Counterparty Mismatch

TK06

Token Found with Value Limit Rule Violation

TK07

Single Use Token Already Used

TK08

Token Suspended

NOAT

Receiving Customer Account does not support/accept this message type

OK

Completed

1100

Any Other Reasons Reason is provided as narrativein the additional information

9909

Central Switch (RTP) system malfunction

9910

Instructed Agent signed-off

9912

Recipient connection is not available

9934

Instructing Agent signed-off

9946

Instructing Agent suspended

9947

Instructed Agent suspended

9948

Central Switch (RTP) service is suspended

TransactionAccountContext is a CR code used internally for additional detail for the state of a payment within a status. PaymentStatus should be used for determining the status of a payment.

Context

Description

NotSubmitted

Payment has not been been sent to the RTP Network

Pending

Payment is in a pending state

Processing

Payment is processing

Complete

Payment has completed

Reversal

Transaction is being reversed

MemoPost

Attempting to set a Memo Post

TimedOut

Action has timed-out

Canceled

Action has been canceled

Rejected

Payment has been rejected

AuthOnly

Authorizing a transaction

NotSet

Not Set

Status of the payment, as set by the receiving institution. This applies to Credit Transfers.

Status

Description

ACTC

Payment has been accepted

RJCT

Payment or Payment Related Message has been rejected

RCVD

Payment Related Message has been received by the receiving institution

ACWP

Payment instruction included in the Credit Transfer is Accepted without being posted to the Creditor Customer’s account

SDVA - The only code accepted by RTP, which means payment must be executed with same day value to the creditor (for RTP this will be done in seconds)

Identifies the origination condition of the instruction to allow the instructed agent to properly process the transaction

Code

Description

INTERMEDIARY

Payment sent through a Payment Service Provider (domestic) – one of “Ultimate Debtor” or “Ultimate Creditor” must be present

STANDARD

Standard RTP payment

Identifies the Debtor/Sender as either a business or consumer customer of the Debtor FI

Code

Description

BUSINESS

Business initiated

CONSUMER

Consumer initiated