Instant payments at Cross River

Cross River is proud to offer a suite of domestic Instant Payments products. Instant payments allow individuals and businesses to transmit funds that clear and settle within seconds between US DDAs at different US-based financial institutions. Cross River (CR) uses the following payment network platforms to route its instant payments:

  • RTP® via The Clearing House. The Clearing House (TCH) provides Instant Payments using its RTP® system. All federally insured US depository institutions that participate in the RTP network can send payments from and receive payments to their accounts 24/7.

  • FedNow®. The Federal Reserve's instant payment infrastructure allows financial institutions of every size across the U.S. to provide safe and efficient 24/7 instant payment services.

Instant Payments are not permitted for foreign payments. These are domestic-only networks, which means that an instant payment cannot be sent to a foreign bank. To further elaborate, Instant Payments may not be used at any point in a transaction flow where the funds are either being sent to or received from a foreign bank. The Instant Payment leg of a flow of funds must be considered a separate transaction from the foreign payment leg.

Instant Payments flow

Features

  • Any US-based bank can join either Instant Payments network to send domestic transactions.

    Note

    Both sending and receiving banks must be part of the same Instant Payments network to send a payment over that network. Each participating bank on either network 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.

  • You can't reverse a transaction or get a returns automatically with Instant Payments. If you need to ask for your money back, you have to ask for a Return of Funds from the bank that you sent the payment to.

  • Each network defines any explicit limitations on Instant Payments use cases for that network.

  • TCH sets its transaction limit at $1,000,000/transaction. FedNow sets its transaction limit at $500,000/transaction. Cross River may set different limits for different partners. These limits are subject to review.

    For example, it could be that a Cross River partner is only approved for Instant Payments transactions under $10,000.

  • For receiving funds, Cross River doesn't set a receive limit that is lower than the maximum receive limit, i.e., $1,000,000 for TCH and $500,000 for FedNow.

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

How Instant Payments works

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 that sends the credit transfer, and the creditor FI is the bank that receives the credit transfer. This is the same thing as a push payment. One party (debtor) sends funds to another party (creditor).

Instant Payments networks do not use pull payments. 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.

Originating Instant Payments using COS

Originate Instant Payments using Cross River COS API calls. A credit transfer via API call must include at least:

  • The account number funding the transfer

  • The transfer amount

  • The creditor account number and routing number at the receiving bank

Network interoperability

CR now uses two different Instant Payments network platforms: RTP via The Clearing House (TCH) and FedNow. Until recently, only TCH offered instant payments. Now we can also originate Instant Payments through the Federal Reserve's FedNow platform.

CR network interoperability solution delivers the payment to the creditor as efficiently and effectively as possible. When you originate an Instant Payment:

  • If both networks are available and online, we use a "network preference." We base this preference on the product configuration, which can either be a CR level network preference or you can choose your own preference, applied across all your users of that product.

    • You can also indicate your preference for an individual transaction using the networkPlatform attribute on the API request.

  • If only one network can be used, we route the payment through that network.

  • If both networks can be used but only one is online, we use that online network.

  • If neither network can be used, the payment fails.

To determine if an FI (based on routing numbers) participates in either or both platforms, use the directory endpoint.

Network platform values

When you originate an Instant Payment credit transfer, the response returns one of these values for the networkPlatform attribute.

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

Queuing Instant Payment

Cross River has created a user experience for partners to submit Instant Payments to participating banks when they are unavailable to receive the payment. Instead of the payment being rejected, CR will queue the payment until the receiving institution is online, and then automatically originate the payment. Queuing is available for both RTP via TCH and FedNow.

What FIs are on what network?

Cross River offers an API to find out whether a given FI participates in RTP via TCH, FedNow, or both, and what services that FI offers. Use the GET /rtp/v1/directory endpoint. See our tutorial about this endpoint.

Instant Payments use cases

Transfer funds with instant payments for a variety of use cases.

Person to Person (P2P)

  • Caregivers - Babysitters and Dog Walkers

  • Gift giving/funding - Birthdays, Baby or Bridal showers

  • Micro-lending/micro- donations - GoFundMe page or Fundraising site

  • Reimbursements - Splitting checks, Rent or Utilities

  • School expenses

Business to Business (B2B)

  • Merchant Settlement

    • E-invoicing (recurring complex invoices)

    • Automation of sub-contractor invoices

  • Reduction in manual efforts for reconciliation

  • Just-in-time payments/payment on delivery

    • Services (background checks, drug screenings, uniforms)

  • Off-cycle payments

  • 401(k) loan disbursements

  • Benefits disbursements

  • Payments for pension, 401(k)

  • Reimbursing travel or home office expenses to employees

Business to Consumer (B2C) or Business to Business to Consumer (B2B2C)

  • Digital Wallet disbursements

  • Loan funding

  • Insurance claims auto/home

  • Employer Benefits (401(k) loans, pension payments)

  • Legal settlements

  • Reimbursements

  • Refunds

Consumer to Business (C2B)

  • Loans/credit cards

  • Recurring monthly bills - Cable/internet service, Utilities, Rent, Rentals (furniture, etc.)

  • Homeowners’ association dues

  • Medical bills

Instant payments roles

Role name Description

Debtor (Payer)

The person or company that wishes to send a payment via instant payments

Debtor (Payer) FI

The financial institution sending the Instant Payments payment. Also known as the sending participant or participating FI

The Instant Payment system

The network for routing and settling Instant Payments between participating FIs:

Either RTP via TCH or FedNow

Creditor (Payee) FI

The financial institution sending the Instant Payments. Also known as the receiving participant or participating FI

Creditor (Payee)

The person or company receiving a payment via instant payments

Requester

The person or company requesting information on a payment made (RFI) or a return of funds sent (RFR)

Ultimate Debtors and Creditors

The ultimate debtor and creditor roles offer the receiving bank greater clarity about the exact originator or recipient of the funds.​ These roles are useful whenever there are 2 parties on either the sender side (debtor) or the receiver side (creditor) (or both) because one party is originating or receiving on behalf of the other party. Ultimate debtors and creditors make clear to the receiving bank who the exact originator or recipient of the funds is.​ ​This helps ensure accurate and efficient processing of transactions within the financial system.

You're 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.

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

The diagram below provides variable flows of funds with Ultimate Debtors and Creditors.

The second flow shows a practical application of how to use the Ultimate Debtor in Instant Payments API requests:

  1. The Sender, an end user, initiates the payment or disbursement via the Merchant's application.

  2. The Merchant, your client, both provides the platform through which the Sender initiates the payment and acts as the Ultimate Debtor.

  3. You act as the Debtor in this scenario because you are directly affiliated with Cross River, and serve as the client of the bank.

  4. Cross River, as the Sending Financial Institution (FI), facilitates and oversees the transaction.

  5. The Receiving FI, as the recipient financial institution, obtains the payment on behalf of the final beneficiary.

  6. The Receiver, as the end beneficiary or creditor and a client of the Receiving FI, receives the disbursement or payment.

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 in COS (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 are various requirements for specific customers to use Instant Payments with CR. All these requirements are included in the due diligence process, ensuring that the customer 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

  • In the case of RTP via The Clearing House (TCH) instant payments, 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 for RTP via TCH are outlined in TCH's RTP Operating Rules and Legal and Regulatory Compliance Guide related to Payment Service Providers (PSPs).

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.

Business reference information

Payment status

See the payment status in the status field of Instant Payment responses.

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 Instant Payments 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

*A final status for a payment

Payment types

This value appears in the paymentType field in Instant Payments responses. The paymentType value tells you details about the transaction.

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.

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 that has been received

This is a non-monetary transaction

PaymentAck*

A Creditor 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

*This payment type is not currently supported

RTP via TCH and FedNow error codes

RTP via TCH and FedNow return their own, specific error codes. See the error codes value in the result.code field of the response.

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

Refer to the ISO 20022 External Code Set on ISO’s website for additional information on FedNow reason codes.

Error Code

Error Description

E301

Report request failed. Review request, update and resubmit as needed.

E400

ISO message does not exist, can resend with same message ID (or new message ID).

E401

Sender of the payment status request is not authorized to receive transaction status.

E402

Original ISO message referenced was not processed; resend with new unique message ID.

E411

Transaction is still processing; retry after timeout clock has elapsed.

E481

Invalid dates included in the reporting from date and/or to date fields.

E500

Internal processing error; contact FRB Service Support Center.

E600

Balance inquiry is not allowed for this account or by this Participant.

E760

Invalid response sender and receiver. Response sender and receiver must match original transfer request.

E890

Pending transaction status is not valid for this message.

E891

Finalized transaction status is not valid for this message.

E960

Internal error. Contact FRB Services Support Center for details.

E970

Invalid settlement relationship. Sender FI and Receiver FI must have a valid settlement relationship within the FedNow Service to indicate the appropriate Master Account to which transactions will be settled.

E974

Internal processing error; contact FRB Service Support Center.

E980

Invalid FedNow Service profile for the Sender FI RTN. As a result, the RTN is not eligible to send this message type.

E981

Invalid FedNow Service profile for the Receiver FI RTN. As a result, the Receiver FI RTN is not eligible to receive this message type.

E982

Sender FI or Receiver FI does not have a Participant Profile enabled to send and/or receive instant payments;

or Receiver FI does not have a Participant Profile enabled to receive Request for Payment (RfP) messages.

E983

Liquidity Management Transfers (LMTs) were sent outside of supported hours. LMTs can be sent only during specified LMT operating hours.

E984

Sender FI or Receiver FI does not have a Participant Profile enabled for the indicated RTN to send and/or receive LMTs.

E990

Invalid transaction limit. Transaction exceeds the FedNow Service transaction limit, or a lower limit set by the Sender FI.

E996

Reserved response timeout. Insufficient time remains on the payment timeout clock to accommodate Receiver FI reserved response time.

E997

Timeout clock has expired. Processing of the transaction exceeded the payment timeout clock.

E998

  • Receiver FI is not signed onto the FedNow Service and therefore cannot receive instant payments.

  • Sender FI and/or Receiver FI is not yet active on the FedNow Service.

E999

ISO message has a creation date or timestamp that is in the future from when it was received by the FedNow Service. This is not allowed.

T501

ISO message exceeds the maximum allowable size of 25,000 characters.

T504

Invalid clearing system member ID field. The ID in the “to” component should be the FedNow Service member ID (e.g., "021150706").

T505

ISO message does not meet the FedNow Service ISO 20022 message specifications for one or multiple fields.

T506

Invalid message definition identifier. This identifier should be associated with the underlying message and must be a version that FedNow Service supports.

T508

Business processing date/time element is not allowed in the ISO message. This element is used only by the FedNow Service.

T509

Copy duplicate element is not allowed in an ISO message sent by a Participant. This element is used only by the FedNow Service.

T510

Related element is not allowed in an ISO message sent by a Participant. This element is used only by the FedNow Service.

T512

Invalid message ID. A valid message ID must meet the following criteria:

  • Calendar date (CCYYMMDD) is the current date and aligned with the Business Application Header (BAH) date.

  • Connection Party ID (nine alphanumerical characters).

  • Reference sequence assigned by sender (up to 18 characters).

T514

Structured remittance information field exceeded the maximum length of 4,000 characters.

T515

Message contains both structured and unstructured remittance elements. The FedNow Service only allows one or the other within a single message.

T516

Invalid sending party or sending party information. A valid sending party is a Participant or a Service Provider that is authorized to send messages on behalf of the Participant.

T517

ISO message ID is a duplicate. The message ID must be unique.

T518

ISO message does not contain an original transaction ID or original UETR. The ISO message must contain one or both.

T519

ISO message does not contain a phone number in the preferred contact Method (PHON) field. A phone number must be provided when phone is the preferred contact method.

T520

ISO message does not contain a mobile number in the preferred contact method (CELL) field. A mobile number must be provided when cell is the preferred contact method.

T521

ISO message does not contain an email address in the preferred contact method (MAIL) field. An email address must be provided when mail is the preferred contact method.

T522

ISO message does not contain the required status reason code for the rejected transaction.

T523

Invalid transaction status code. ISO messages must include one of the following eligible codes:

ACTC

ACWP

ACCC

BLCK

PDNG

RJCT

T524

Invalid original message name identification. A valid ISO message name as permitted in the ISO 2022 message specification rules is required.

T525

Invalid original interbank settlement amount format. This amount must be:

  • Greater than $0

  • Maximum of two decimal places

T526

Insufficient information provided. When debtor of the return is a party, the debtor party, account and agent must be provided.

T527

Invalid local instrument. The local instrument specifies the FedNow Service product code under which the message is sent. The code should be FDNA.

T528

Invalid returned interbank settlement amount format. This amount must be:• Greater than $0.• Maximum of two decimal places.

T529

Invalid message signature on ISO 20022 message. For the signature to be valid, it must be signed with the key owner’s private key that corresponds to an active public key that was previously created and validated by the FedNow Service.

T530

Invalid country code. See the officially assigned code list on the ISO 20022 website (www.iso20022.org).

T532

Invalid interbank settlement amount format. This amount must be:

  • Greater than $0

  • Maximum of two decimal places

T533

Invalid compensation amount. This amount must be:

  • Greater than $0

  • Maximum of two decimal places

T534

ISO message does not contain the required transaction identification or UETR.

T535

Invalid category purpose field. This field must contain either CONS, BIZZ or GOVT.

T536

Insufficient information. If the ISO 20022 message used reason code is NARR, additional information or additional incorrect information must be present, as applicable.

T537

Key signature algorithm not supported.

T538

Account balance request cannot include a reporting period because the balance is as of a particular date and time.

T539

Account balance request must include the account type.

T540

If an account balance report (ABAR), account activity totals report (AATR or IATR) or an account activity details report (AADR) is requested, then the member identification field must be the FedNow Service Connection Party identifier of the requestor of the report(s) and must match the "From" field in BAH.

T542

Invalid Market Practice Identifier

T543

Invalid original message date. Original message date must be the current date or previous calendar date.

T544

Message referenced in admi.007 is not found

T545

Reporting Period and Account Type are not allowed for an intraday account activity totals report (IATR) or a correspondent intraday account activity totals report (CITR).

T546

Invalid Account ID for message type. A correspondent account activity totals report cannot be requested for a single RTN.

T547

Invalid status code. The status code must be TS02.

T548

Invalid charges amount format. This amount must be:

  • Greater than $0

  • Maximum of two decimal places

T550

Invalid status confirmation code for the return request response message. Must contain one of the following codes:

  • IPAY

  • RJCR

  • PDCR

  • PECR

T551

Cancellation Status Reason Information component is incorrect:

  • Reason code is required if status confirmation code is ‘RJCR.’

  • Only one instance of the Cancellation Status Reason Information component is allowed

T553

Proprietary under Reason cannot be populated.

T554

Invalid status code for the information request response message. Must be one of the following codes:

  • IPAY

  • IDUP

  • INFO

  • NINF

  • PDNG

T555

Incorrect format in fnclockstart field. Refer to the Technical Specification document for the correct format.

T556

Invalid Correction Transaction component in information request response message. If the correction transaction component is present, the status must be “IPAY.”

T557

If an (end-of-day) account activity totals report (AATR), an (end-of-day) account activity details report (AADR), a (end-of-day) correspondent account activity totals report (CATR), or a (end-of-day) correspondent account activity details report (CADR) is requested, then Reporting Period is mandatory, and Account Type is not allowed.

T558

Invalid Requested Message Name Identification in the camt.060 message. A valid ISO message name as permitted in the ISO 20022 message specification rules is required.

T560

Invalid Transaction Status Code. Must be one of the following codes:

  • ACTC

  • PRES

  • RJCT

  • RCVD

T561

The Status Reason Information component can only occur once

T562

The Business Service element in the BAH must not be used by participants

T563

Invalid Status Confirmation code. Must be one of the following codes:

  • CNCL

  • RJCR

  • PDCR

T565

If the Resolution Related Information is populated, the status must be IDUP

T566

If the Resolution Related Information is populated, the status must be either IPAY or PECR

T570

Invalid key encoding. The encoding algorithm must be one supported by the FedNow Service.

T571

Invalid key algorithm. The key algorithm must be one supported by the FedNow Service.

T572

Invalid encoded key. Unable to parse the key using the given encoding and key algorithms.

T573

Invalid key length

T574

Invalid key fingerprint

T575

Invalid key expiration. Keys with an expiration date greater than one year are not accepted by the FedNow Service.

T576

Duplicate key. All keys added must be unique.

T580

Event Time future dated

T581

Error in event code field. If Event Code-FPON/FPOF then Event Parameter must be 9-digit RTN. If Event Code-FPCD/FPCR then Event Parameter must be 7-digit Hexa decimal (connection point ID).

T584

At least one connection point must be connected per Connection party.

T600

Balance inquiry service not available at this time. Or balance inquiry not allowed for this account.

F101

Entry pair matches the Receiver FI’s fraud controls

F002

Entry pair matches an entry on the Sender FI’s Negative List with a send restriction

Reason codes

The reasonCode attribute in an Instant Payments response provides the reason a message did not complete. The resultCode will be OK if the payment was successfully sent/received.

Refer to the ISO 20022 External Code Set on ISO’s website for additional information on FedNow reason codes.

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

BE01

Inconsistent end customer (FedNow specific)

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

RR04

Regulatory reason (FedNow-specific)

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 narrative in 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

Transaction account context

TransactionAccountContext is a CR code used internally for additional details about the state of a payment, within a status. Use PaymentStatus to determine the status of a payment with regard to the Instant Payments network.

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

Transaction Status

Network status of the payment (rtpTransactionStatus), as set by the receiving institution. This applies to Credit Transfers.

Status

Description

Network platform

ACTC

Payment has been accepted

TCH, FedNow

RJCT

Payment or Payment-related message has been rejected

TCH, FedNow

RCVD

Payment-related message has been received by the receiving institution

TCH

ACWP

Payment instruction included in the credit transfer is Accepted but not yet posted to the Creditor’s account

TCH, FedNow

ACCC

Payment has posted to the Creditor Customer's account

FedNow

ACSC

Accepted settlement completed

FedNow

BLCK

A payment instruction that previously had an ACWP status is blocked. Funds will neither be posted to the Creditor's account nor returned to the Debtor's account. (FedNow specific)

FedNow

PDNG

A payment instruction that had an ACWP status still has not posted to the Creditor's account (FedNow specific)

FedNow

ServiceLevelCode

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

LocalInstrumentProprietary

For RTP via TCH, 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

CategoryPurpose

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

Code

Description

BUSINESS

Business initiated

CONSUMER

Consumer initiated

Code

Description

BIZZ

Business initiated

CONS

Consumer initiated
GOVT Government initiated

Error codes

Instant payments COS system error codes can be retrieved in the RTP module using the call GET /v1/meta/errors.

Code

Description
2000 General exception
2001 Payment not found
2002 Invalid payment status
2003 Original Payment Not Found
2004 Return Request must be inbound and in a pending state to be rejected
2005 Credit transfers must be outbound in a hold status to be rejected
2006 Payment type can not be rejected
2007 Direction not inbound
2008 Direction not outbound
2009 Payment cannot be canceled
2010 Payment must be outbound
2011 Payment must be inbound
2012 Payment cannot be competed
2013 Routing number isn't a valid RTP Participant
2014 Payment does meet criteria to be resent
2015 Payment had already been refunded
2016 Ultimate Debtor can only be used when account is a business account
2017 Payments of $3,000 or more require a complete debtor address
2018 Invalid Debtor
2019 Return can not be requested for a Credit Transfer due to payment status
2020 Return can not be requested for an inbound Credit Transfer
2021 Only Credit Transfers can be refunded
2022 Payment already has an existing Return Request in process
2023 Payment must be a Return Response
2024 Payment must be awaiting response
2025 Return Request was not found
2026 Credit Transfer was not found
2027 Cannot manually update payment, funds will be returned through RTP Network
2028 Simulator-Credit Transfer must be inbound
2029 Payment has already been accepted
2030 Credit Transfer status must be Completed
2031 Payment already has an existing Payment Ack in process
2032 Payment can not manually be updated with funds received from an alternate rail
2033 Payment AwaitingResponse already set to submitted status
2034 AwaitingResponse is not a settable property for this payment type
2035 AlternatePaymentDetail is not a settable property for this payment type
2036 Response has already been sent for payment
2037 Invalid amount specified
2038 Payment has expired
2039 ReasonCode is missing or invalid
2040 AdditionalInfo cannot be used with specified ReasonCode
2041 Payment must be a credit transfer
2042 AdditionalInfo is required for specified ReasonCode
2043 Invalid Creditor
2047 Requested Execution Date cannot be after Expiry Date
2048 Requested Queued Payment Expires At Date has already passed
2049 Participant is not active
2050 Debtor does not support Return Payment
2051 Unsupported message type on specified network platform
2200 Global profile change not pending
2201 Global profile not found or is invalid
2202 Global Change not approved
2203 Global config change approval requires dual control
2204 Global config required
2205 Global config accounts must be unique
2206 Offset account not found
2207 Unposted account not found
2209 Account change not approved
2210 Account change not pending
2211 This action requires dual control
2212 Account has not been enabled to send credit transfers
2213 Account config change approval requires dual control
2214 Account configuration not found or is invalid
2215 Product change not pending
2216 Product change not approved
2217 Operator Account not found
2218 Product config change approval requires dual control
2219 Account config required
2220 Product config required
2221 Custom originator data not allowed for account
2222 Max payment amount exceeded
2224 Daily Total Dollar Amount Sent Limit Exceeded
2225 Daily Total Dollar Amount Received Limit Exceeded
2226 Daily Sent Transfer Count Limit Exceeded
2227 Daily Received Transfer Count Limit Exceeded
2228 Birth Fields should not be defined on Business Products
2229 Legal Entity Id should not be defined on Personal Products
2230 Enabling Payment Request Receive requires Credit Transfer Send to also be enabled
2231 Enabling Payment Request Send requires Credit Transfer Receive to also be enabled
2232 Account has not been enabled to send Payment Requests
2233 Custom originator data not allowed for account
2234 Daily Sent Payment Request Count Limit Exceeded
2235 FedNow Operator Account not found
2236 Enabling FedNow Payment Request Receive requires FedNow Credit Transfer Send to also be enabled
2237 Enabling FedNow Payment Request Send requires FedNow Credit Transfer Receive to also be enabled
2300 Hold is not active
2301 Hold is not evaluating
2302 Manual holds can only be placed when the payment already has a status of hold
2350 Public key ID already exists
2351 Public key ID does not exist