Payment Screening for Incoming ACH Credits

Payment screening is a fraud-detection service designed to help prevent fraudulent incoming ACH credits by flagging high-risk deposits for manual review. By combining manual reviews with automated processing for recurring deposits, the service helps provide efficient handling of direct deposits while minimizing risk. Whether reviewing first-time deposits, flagging irregular transactions, or creating custom rules to meet specific needs, this feature empowers you to maintain robust fraud-prevention measures. For advanced integrations or support, Galileo provides dedicated tools and expert teams to assist your operations.

Additionally, Galileo offers the flexibility to handle flagged transactions either internally or via Galileo’s dedicated Fraud Operations Team. For integration specifics, contact Galileo.

Key capabilities

• Send all incoming ACH credits for manual review, or send tax credits only.
• Following manual reviews, you can either post transactions on their scheduled settlement date or force-post them immediately, overriding load-limit checks when necessary.
• Ensure appropriate return codes are applied to transactions.
• Flag a transaction for a second review after an initial inspection.
• Produce reports detailing transactions sent to manual review, including the actions executed.

How it works

This feature is based on an ordered set of rules that you define to apply during incoming transaction processing. Galileo applies the rules based on preset thresholds (standard and premium) and can include optional keyword searches within transaction details. You can use these thresholds and searches to approve or reject an incoming credit or send it to manual review. The goal of deposit reviews is to complete proactive examinations of pending deposit details and associated account holder information for evidence of fraud. While reviewing transactions under manual review, recurring deposits can be set to be automatically approved, rejected, or watched (not applicable to receiver-name mismatches).

📘

Note

Recurring deposits must contain identical data strings. If any of the data changes on the next deposit, it will not be auto-approved and will go to manual review. This includes variations in the name, punctuation, capitalization, spacing, dollar amount, originator, receiver, category, and account number (PRN).

Standard rules

These standard rules are the most commonly used from program to program. Galileo will work with you to establish custom rules suitable for your program.

• Unverified Direct Deposit — Applies to direct deposits that are from an unfamiliar originator for the receiving cardholder. Each new direct deposit will be manually reviewed the first time it is received. Once approved, repeats of the same direct deposit can be processed automatically.
• Use case — You want anything over $100 without a matching name (data stream) or prior approval to be held for manual review and approval. After a deposit is approved, you only want to see the payment hold again if it exceeds 5000.00. Anything 9500.00 or higher should be auto-rejected. Any payment below 100.00 can be auto-posted by the system (as long as it doesn’t trigger any of these other parameters).
• Large Amount — Maximum amount limits applied to all ACH direct deposit transactions. Once approved, future matching deposits will automatically post unless they exceed the premium threshold amount.
  • Use case — You want any non-tax deposit 2000.00 or higher without prior approval to be held for manual review. After a deposit is approved, you don’t want to see it held again unless it exceeds 6000.00. Anything 9500.00 or higher should be auto-rejected. Any payment below 2000.00 can be auto-posted by the system (as long as it doesn't trigger any other parameters).
• Tax — Limits applied to all ACH tax return direct deposits. Once approved, future matching deposits will automatically post unless they exceed the premium threshold amount.
  • Use case — You want any tax deposit 1.00 or higher without prior approval to be held for manual review. After a deposit is approved, you don’t want to see it held again unless it exceeds 1000.00. Anything 9500.00 or higher should be auto-rejected. Any payment below 1.00 can be auto-posted by the system (as long as it doesn’t trigger any of the other parameters).
• International – Applies to any direct deposit originating from a country listed on your auto-return or manual review lists.
  • Use case — You want any direct deposit from Albania, Bosnia, or Iraq to be queued for manual review. Any direct deposits from Cuba, Burma, or Sudan are to be automatically returned.
• Payday Loans — Applies to any direct deposit from a payday company listed on your payday companies list.
  • Use case — You want any payday deposit 1000.00 or higher without prior approval to be held for manual review. After a deposit is approved, you don’t want to see it be held again unless it exceeds 5000.00. Anything 9500.00 or higher should be auto-rejected. Any payment below 1000.00 can be auto-posted by the system (as long as it doesn’t trigger any of the other parameters).

Name matching

There are two different methods available for name verification on incoming ACH credits.

Unverified Direct Deposit

As previously mentioned in the standard rules list, Unverified Direct Deposit is used to flag incoming ACH credit transactions with a new ACH originator and PRN combination and are more than or equal to a configured dollar amount, then they should be sent for manual review. Incoming ACH credits do not undergo automatic name-checking by default. An agent reviews the deposit and the names on the transactions manually, then decides if they want to approve or reject and allow the originator for future transaction posting.

Receiver Name Matching

For name matching to happen automatically, Receiver Name Matching must be enabled. Receiver Name Matching is a premium feature that is used to detect fraud by automatically inspecting incoming ACH credit transactions for receiver name mismatches. It verifies whether the name associated with the transaction aligns with the name on the receiving account that is registered in the Galileo system. When names match, the transaction undergoes regular processing, followed by validations against controls such as amount thresholds and load limits. Mismatches can result in transactions being flagged for manual review.

When enabled for all ACH credits, each incoming transaction is screened for name alignment, flagging discrepancies for manual review. Alternatively, you can configure this feature to focus on tax-specific credits, where only federal tax and selected state tax credits are verified for name alignment. See the example scenario below.

📘

Note

Auto-posting of future transactions cannot be configured for Receiver Name Matching.

Questionable tax refunds

Payment screening can be set up to help identify suspicious tax refunds when the standard rule for tax deposits is configured and Receiver Name Matching is enabled.

ACH transactions are automatically inspected to determine if they are a federal deposit or a tax return. The payment screening function proceeds to compare the name in the incoming ACH transaction to the name in Galileo's system (Receiver Name Matching).

• If name-matching is a success, the transaction is processed as normal and validated against any other rules configured for the program.
• If name-matching fails, the transaction is sent to manual review, where it requires further action from the operations manager (either on your side or Galileo's). The category of the transaction is flagged as RNM. See the Payment screening process section, below, for more details.

This scenario can be tested in a CV environment. Refer to the Payment screening for tax refunds simulation guide for step-by-step instructions.

Payment screening process

This process applies to deposits that have triggered a hold for manual processing based on various thresholds and dollar amounts. Galileo offers two methods to perform manual review: the CST or with the Get Pending Deposits and Modify Pending Deposits endpoints.

Via CST

Access the queue in the Payment Posts & Returns page. Review the basic cardholder information and basic deposit sender information to determine if the deposit should be approved, watched, or rejected. This is where name matching can be performed, as the account holder information includes the name on the account and the recipient name for the deposit . Once actioned to be posted, deposits can be viewed on the Direct Deposit View page.

Reach out to Galileo for access to the Payment Posts & Returns guide for more information.

Via Program API

When using the Program API, this workflow consists of three simple steps:

1. Call Get Pending Deposits to retrieve a list of incoming ACH credits pending manual review.
2. Look for transactions with category_code: RNM (name mismatch).
3. Call Modify Pending Deposit Status with the decision to approve or reject each RNM transaction. You will modify the following fields:

📘

Note

If you reject the transaction, use the return code R17 to indicate that the entry was initiated under questionable circumstances. This return code is available only to programs with sponsor bank approval.

Events API

The receiver_name field can be added to the BPMT message by request. This adds the name field from the ACH record to ACH payments. This field will be blank or may contain other information on non-ACH payments.

Galileo setup

Refer to the ACH table on the Parameters page for details on ACH-related settings.