Reviewing FedNow Payments

With FedNow Manager, you can review individual payments received and view their details.

In this article:

• Review Payments

• Search and Filter Payments

• Payment Statuses

• Request Information on a Payment

• Handling Posting Failures

• Request a Return

  • Return Request Reasons

Review Payments

To review payments:

1. From Narmi Command, select Transactions > FedNow manager.

2. Select the Payments tab to view a list of payments with the following information:

   • Payment ID – A unique ID associated with the payment; this ID is provided by the FedNow system.

   • Source – Sender’s account number

   • Destination – Recipient’s account number

   • Last Updated – Date and time the payment was last updated

   • Status – Status of payment, see descriptions of Payment Statuses below.

   • Amount – Dollar amount of payment
     

     
     

3. Select a payment row to open a side panel that displays that payment’s details. This includes:

   • Banner – A yellow banner shows for payments that have an open case. Select View request to open the related case.

   • Payment details – This includes:

     • Payment ID – A unique ID associated with the payment; this ID is shared throughout the FedNow system, including with the counterparty FI.

     • Core transaction ID (if available) – The ID for the transaction returned from the core at posting. Note: for some cores, this transaction ID can change at a later time.

     • Status – Go to Payment Statuses for more information.

     • Amount

     • Direction – Incoming or Outgoing

     • Memo (optional)

     • Effective settlement date – The FedNow cycle date for the settlement

   • Source –  The sender’s name (individual or business), account number, and routing number

   • Destination – The recipient’s name (individual or business), account number, and routing number

   • Payment History – The status history of the payment with date and time stamps

   • Related Payments – ID of related payment(s); select to open details

   • Related Cases – ID of related case(s); select to open details

   • Copy link – On the upper right, select this to copy the payment details URL
     

     
     

4. Select the “X” to close the side panel.

Search and Filter Payments

To search for a specific payment, in the Payments tab, enter the payment ID, account number, or routing number in the Search box, and select Search.

You can filter the payment list to quickly find what you need, such as filtering by payment status to easily find payments needing manual review.

To filter the Payments list:

1. In the Payments tab, select the filter icon in the Search box.

   

2. A side panel appears with the following filter options:

   • Payment Status – Filter by a specific payment status. Go to Payment Statuses for descriptions.

   • Direction – Filter by transaction type, either Incoming or Outgoing

   • Last Updated – Filter by the payment’s last updated date

   • Amount – Filter by payment amount

3. Select Apply.
   

Payment Statuses

Payments can have one of the following statuses:

• Pending Validation – Credit transfer has been received and is being validated.

• Accepted – Transfer has been accepted (FedNow status is ACTC).

• Rejected – The transaction was rejected by the receiving institution/Narmi (FedNow status is RJCT).

• Rejected (FRB) – The transaction was rejected by the Federal Reserve Banks (FRB) after being accepted by Narmi (FedNow status is RJCT).

• Rejected Reversed – An outgoing transaction was rejected and the posting has been reversed.

• Rejected Pending Reversal (Applies to BaaS For Benefit Of accounts only) – An outgoing transaction was rejected and the posting has been reversed on the core but is pending confirmation of the reversal on the BaaS ledger.

• Settled – The transaction was settled by FRB (FedNow status is ACSC).

• Posted – The transaction has been successfully posted to the customer’s account (FedNow status is ACCC).

• Accepted Without Posting – Payment was flagged during validation and has an open ACWP case pending review.

• Blocked – A staff member decided to block the payment during the ACWP review.

• Awaiting Response – Narmi has sent an initial credit transfer message and is waiting for a response on whether it is accepted.

• Pending Final Posting (Applies to BaaS For Benefit Of accounts only) – Transaction has been posted on the core but is pending posting confirmation from the BaaS platform.

• Posting Failed – The transaction could not be posted to the core. (This is a non-terminal error state and requires staff action).

• Final Posting Failed (Applies to BaaS For Benefit Of accounts only) – The transaction was posted to the core but could not be posted to the BaaS ledger.

• Manually Resolved – Terminal state for payments that were not automatically posted and were either returned or manually resolved in some other way.

Request Information on a Payment

When you find a potential issue with a posted payment, you can request information, which opens a new case. (To request information on an AWCP case, go to Request Information on a Case.)

To request information:

1. From Narmi Command, select Transactions > FedNow manager.

2. Select the Payments tab and select a payment row.

3. In the side panel that appears, select the three dots and choose Request information.
   

4. In the dialog that appears, select a Justification:

   • Missing information – Information is missing; for this justification, you have the option to flag it as an “Anti-money-laundering request”

   • Incorrect information – Information is incorrect; for this justification, you have the option to flag it as an “Anti-money-laundering request”

   • Possible duplicate instruction – Instruction ID is not unique

5. Enter a Narrative to support the request (up to 140 characters). Select Submit.

   

Handling Posting Failures

For payments in “Posting failed” or “Final posting failed” status, you can return the payment and/or mark it as manually resolved.

To return payment or mark it as manually resolved:

1. From Narmi Command, select Transactions > FedNow manager.

2. Select the Payments tab and select a payment in “Posting failed” or “Final posting failed” status.

3. In the side panel that appears, select the three dots and choose one of these options:

   • Return payment – This creates a return payment to the sender in full and marks it as status ”Manually Resolved.” The previously deposited funds will be withdrawn from the core account.

   • Manually resolve – This marks the payment as status ”Manually Resolved.” No automated action will be taken.
     

4. If returning, choose a Return reason, then select Confirm. For a list of return reasons, go to Resolution Reasons.

   

   
   If manually resolving, select Confirm.

   

Request a Return

The Sender FI can request to return a payment previously sent through the FedNow Service. To request a return for an outgoing payment:

1. From the Payments tab in FedNow Manager, select a payment with “Posted” status.

2. On the side panel that opens, select the three dots on the upper right, then select Request a return.

   
   

3. Specify a reason for the return request, and optionally provide additional information. For a list of return request reasons, go to Return Request Reasons.
   
   

4. Select Submit. A return request will be submitted via the FedNow network, and a case will be created in Narmi.

When the counterparty FI responds to the return request, the case will be closed. If a return request is accepted, it will result in a new payment for the return amount, and that payment will show up under related payments on both the original payment and the return case.

Return Request Reasons

Possible return request reasons are:

• Wrong account number in Credit Transfer.

• Agent in the payment workflow is incorrect.

• Amount is not the amount agreed or expected.

• Debtor or Ultimate Debtor identification code missing or invalid.

• Cover payments has either been returned or cancelled.

• Currency of the payment is incorrect.

• Cancellation requested because the original payment order expired due to time-out.

• Invalid date (for example, wrong or missing settlement date)

• Payment is a duplicate of another payment.

• Cancellation requested following a transaction that was originated fraudulently. The use of the FraudulentOrigin code should be governed by jurisdictions.

• To complement a rejection response, suggesting the request for cancelation should be forwarded to the next agent in the payment transaction chain.

• Direct Debit Tracking recalled as Mandate Cancelled.

• To express the wish to establish a bilateral indemnity agreement.

• The underlying transaction in relation to an RTP was modified.

• The underlying transaction in relation to an RTP was already paid (via other means).

• The payment is canceled since a cash amount rendered was not correct or goods or service was not rendered to the customer, e.g., in an e-commerce situation.

• Cancellation requested by System Member to Settlement System Administrator to indicate that the cancellation request must not be forwarded further in the chain

• Cancellation requested following technical problems resulting in an erroneous transaction.

• Payment is not justified.

• Cancellation or request for return requested by the Debtor specifically due to one or more errors by the Debtor in the original Credit Transfer. Usage: This code can be used for any error in the original Credit Transfer made by the Debtor. Can also be used if multiple errors were made in the original Credit Transfer.

• The Debtor is requesting a return of the payment because the payment was not properly authorized. Usage: This code can be used in the case where a Credit Transfer was made without proper authorization from the Debtor. This could be due to compromised end-user credentials.

• Reason is provided as narrative information in the additional reason information.

• Debtor account number invalid or missing.

• Process a cancellation request but batch already settled.

• Process a cancellation request with incorrect reference to original batch.

• Duplication of a request-to-pay message.

• Breach of warranty provided in connection with a request for payment.

• Return of funds requested by end customer.