​
RDFI (Receiving Depository Financial Institution)

​
General information:

  • The platform is able to receive and process CREDITS, DEBITS and RETURNS for all SEC codes, including inbound IAT entries.
  • The platform provides all information about the received transaction to the FinTech: SEC code, amount, Trace ID, Sender data and processing time
  • If a NOC is received, the platform will notify the FinTech OPS to confirm and modify the receiver’s account number
  • The Platform can process and receive future dated ACHs

​
High level ACH received file flow:

​
Receive ACH Pre-requisites:

  • The FinTech customer needs to have a valid account number in the Synctera platform under their Bank partner ABA number
  • The Bank partner forwards the inbound ACH files to the Synctera platform when they receive an inbound ACH file
  • The Synctera platform performs ACH file format validation checks as well as duplicate validation checks on inbound files. If failed, the partner Bank will be notified.
  • An account number exact match is required for a successful inbound payment processing

​
Inbound ACH processing rules:

  • The Synctera platform processes transactions in order as soon as the file is received. First CREDITS High to low and second DEBITS low to high.
  • An account number exact match is required for a successful inbound payment processing
  • Future dated ACHs are validated against account number and stored in the platform until its transaction settlement date where they will posted to the FinTech customer account
  • The Synctera platform creates returns in real time based on NACHA rules and has a Operational manual review for Inbound ACH that need special payment operations attention

​
Inbound CREDITS processing and return generation:

Credit processing: When the Synctera platform receives an Inbound file, after running the file format validations, it will automatically process CREDITS in the file first starting from higher to lower value. In order to process an automated credit posting against a FinTech account the platform needs a 100% match on the account number. When the credit is posted to the receiver’s account, the funds are immediately available to the FinTech customer and all transaction details are included in the transaction data (SEC code, amount, Sender information and addenda record data if present) Return generation: During the inbound CREDIT processing, the platform can find different errors like the account status is closed or frozen, account number does exist, the receiver’s account cannot accept credits or debits. In these scenarios, a return will be generated and sent to the network using the correct return code as per the NACHA rules. When a return is generated, no ACH entry is posted to the FinTech customer account, the entry is instead posted against a FinTech suspense account. That way the platform makes sure that all transactions instructed in the ACH file have been posted against the FinTech accounts.

​
Inbound DEBITS processing:

Debit processing: When the Synctera platform receives an Inbound file, after running the file format validations and processing the credits, it will then process DEBITS. DEBITS will be automatically processed from lower value to higher value against the FinTech customer account. In order to process an automated debit posting against a FinTech account the platform needs a 100% match on the account number. When an inbound debit is posted the funds are debited in real time from the customer account and the ACH transaction details are available to the FinTech customer as part of the transaction data (SEC code, amount, Sender information and addenda record data if present) The Synctera platform does not generate NOCs, if account number is not a match the transaction will be returned Return generation: During the inbound DEBIT processing, the platform can find different errors like the account status is frozen, does not exist or the customer does not have sufficient funds to cover for the debit. In these scenarios, a return will be generated and sent to the network using the correct return code as per NACHA rules. When a return is generated, no ACH entry is posted to the FinTech customer account, the entry is instead posted against a FinTech suspense account. That way the platform makes sure that all transactions instructed in the ACH file have been posted against the FinTech accounts.

​
Inbound CREDIT and DEBITS future dated:

Processing Inbound ACH means that the platform can receive inbound ACH CREDITS and DEBITS that have a settlement date in the future. The settlement date in the future can be up to two business days as per the NACHA rules. When the platform receives an inbound future dated ACH CREDIT or DEBIT, an ACH format and data validation is run as well as an account and customer status validation. If for any reason the account is closed at that time, then the ACH is returned at that time and doesn’t wait until its effective date. The FinTech receives a notification with the details of the inbound future dated payment but the payment is not processed against the end customer account. After running the initial validations, the platform stores the ACH entry until its settlement date and processes the payment on its effective date at 5:00 AM ET, before the first Inbound same-day ACH process for the day.

​
Inbound RETURNS and DISHONORED returns processing:

As part of the Inbound ACH file processing, the FinTech customers can receive returns for previously initiated transactions. In order to process an inbound return, the Synctera platform verifies that the original transaction Trace ID matches the return transaction Trace ID and that the return is within the return time frame, then we will post the return transfer to the FinTech customer account debiting or crediting the account. As a result of the return posting some FinTech customers The Synctera platform informs the FinTech of the inbound return and return code and operationally we advice the FinTech to take special attention and action for the following return codes:
  • R02: Account closed Advice originator not to initiate payments to the receiver’s account and obtain different account
  • R03: No Account - Account number structure is valid, but doesn’t match individual or Open Account Advice originator to validate receiver’s account number
  • R04: Invalid Account - Account number structure not valid, ie edit check digit or number failed Advice originator to validate receiver’s account number
  • R08: Payment Stopped: The customer has requested the stop payment of a specific ACH Debit Entry* Advice originator to review agreements and not to initiate payments to that receiver’s account
  • R12: Account sold to another FI Advice originator not to initiate payments to that account and obtain new account number
  • R16: Account frozen/Entry Returned Per OFAC Instruction - Access to account is restricted due to action by the bank Advice originator not to initiate payments to that account
  • R17: File Record Edit Criteria / Suspicious Entry with Invalid Account No. / Return of Improperly-Initiated Reversal Advice originator to validate receivers account
  • R20: Non-transaction Account - Policies and regulations restrict activity to account indicated Advice originator not to initiate payments to that account
  • R23: Credit Entry Refused by Receiver Validate reason for credit decline with receiver and initiate credit again if needed
  • R28: Routing Number Check Digit Error Advice originator to validate receiver’s account number
  • R29: Corporate Customer Advises Not Authorized Advice originator not to initiate payments to that account

​
Inbound DISPUTE processing:

As part of the Inbound ACH processing, the Synctera platform can receive inbound disputes. The platform disputes all return types that have a 60 day return time frame. The following returns are disputes: R05, R07, R10, R11 and R29. The FinTech is advised to monitor these return types and in the event they receive it for one of their customer accounts, they should not allow their customer to initiate ACH again against the receivers account and additional measurements against the originating account and customer might be taken such as freezing the originator account

​
Inbound NOC processing:

Notification of changes can be received as part of the Inbound ACH process. The Synctera platform can process all types of NOCs. When a NOC is received the ACH Originator is informed via a Synctera Case and the Originator has the obligation to follow up with their customer to verify the external account details and modify the external account details to avoid future NOCs The Synctera platform might receive additional NOCs for that specific external account until the FinTech customer verifies and updates the external account information. Inbound ACH Exception processing: Most of the Inbound ACH processing is automated in the platform including the generation of returns based on the most common errors and validations. In the event the platform receives a debit, credit, return or dishonored return that cannot be automatically posted to the end customer account account then the ACH entry will be posted to a FinTech interim account called ‘suspense’ while the exception is investigated and decided by the Synctera OPS team. When a transaction is posted to suspense for exception handling the Synctera OPS team is notified via the platform and they can login in the Synctera UI to find all information about the Inbound ACH and what type of error triggered the exception. From the Exception processing UI the Synctera OPS agent can decide to return the entry with a valid return code following the NACHA rules or to force post the transactions to the end customer account after approval from the FinTech. Additionally the Synctera platform automatically sends SEC codes “ARC”, “BOC”, “POP” and “RCK” to the manual exception process for review as being rare entries within the network. For details on how what actions are taken as part of the exception process, please see this link

​
Inbound IAT processing and monitoring:

The Synctera platform processes inbound IATs. IATs are subject to additional screening requirements as per NACHA rules. The platform performs AML checks as well as OFAC checks on sender and recipient to process inbound IAT entries. In the event an IAT entry needs to be returned, all the additional addenda information required for the returned processing is included as part of the return as per NACHA rules.

​
RDFI Settlement:

The Bank is responsible to settle with the Fed for all Inbound ACH entries for the ABA number utilized by the Synctera platform to facilitate ACH entries. The Fed settles based on the settlement date