Ingo Payments offers a range of configurable risk controls that can be tailored to your program’s requirements. Your Integration Manager will guide you through selecting the right configuration for your use case during onboarding. This page describes each control, the behaviors it enables, and the risk values available.
Recipient Authentication (RA)
Recipient Authentication is a required feature for programs using Notify — Classic and Notify — Managed Parties. It is used as a fraud prevention mechanism supplementing your KYC process, verifying that the recipient engaging in the disbursement flow is the intended party.
Recipients are challenged against authentication data you provide in the Notify API request. You configure the challenge fields, field order, input format, and the behavior on match and mismatch.
Risk value definitions:
| Value | Behavior |
|---|
| Hard | Reject authentication or prompt the recipient to re-enter (subject to configured max attempts) |
| Soft | Record the event and approve the transaction for the next step |
Recipient Verification Data Matching (RVDM)
RVDM is an optional feature for programs using the IngoPay API and Embedded Account Capture. It compares customer-entered account data against recipient information provided in the API request to detect mismatches that may indicate fraud.
You configure your risk tolerance for each field independently, allowing you to set different responses for high-confidence fields (e.g., name) vs. lower-confidence fields (e.g., address).
Risk value definitions:
| Value | Behavior |
|---|
| Hard | Reject verification or prompt the recipient to re-enter (configurable max attempts) |
| Soft | Record the event and approve the transaction for the next step |
| Bypass | Do not perform verification for this field |
| Field | Risk Values |
|---|
| First Name | Hard / Soft / Bypass |
| Last Name | Hard / Soft / Bypass |
| Address Line 1 | Hard / Soft / Bypass |
| Address Line 2 | Hard / Soft / Bypass |
| City | Hard / Soft / Bypass |
| State | Hard / Soft / Bypass |
| Zip Code | Hard / Soft / Bypass |
| Maximum Attempts | 1–10 |
Address Verification Service — AVS (Card Only)
AVS is an optional feature for card-based disbursements. It compares the billing address entered by the recipient against the cardholder address on file at the issuing bank. Ingo collects the address from the recipient, submits it to the issuer, and handles the response according to your configured risk profile.
AVS is performed during the verify call, via the IngoPay API or the Embedded Account Capture SDK.
Issuers control their own matching algorithms. Ingo has no visibility into individual issuer matching logic — results may vary. Many issuers use fuzzy matching for near-match scenarios.
| Value | Behavior |
|---|
| Hard | Reject the transaction or prompt the recipient to re-enter |
| Soft | Record the event and approve the transaction for the next step |
| Issuer / Network Response | Risk Values |
|---|
| Street address matches; zip does not | Hard or Soft |
| Street address matches; zip incompatible format | Hard or Soft |
| Street and zip incompatible formats | Hard or Soft |
| Zip matches; street address does not | Hard or Soft |
| Zip matches; street incompatible format | Hard or Soft |
| Issuer not an AVS participant or no result returned | Hard or Soft |
| Address information not verified | Hard or Soft |
| Retry — issuer unavailable or timed out | Hard or Soft |
| Maximum attempts | 1–10 |
Card Verification Value — CVV (Card Only)
CVV is an optional feature for card-based disbursements. It verifies that the recipient is in possession of the physical card by requiring entry of the 3-digit security code printed on the card.
When enabled, a full CVV match is required. A mismatch results in a hard failure and the recipient is given a configurable number of re-entry attempts before a terminal event is recorded.
CVV is performed during the verify call, via the IngoPay API or the Embedded Account Capture SDK.
| Setting | Behavior |
|---|
| ON | Full CVV match required for disbursement approval |
| OFF | CVV verification not performed |
Account Name Inquiry — ANI (Card Only)
ANI is an optional feature for card-based disbursements. It verifies that the cardholder name provided by the recipient matches the name held by the issuing bank, providing an additional fraud check during card tokenization.
ANI results are included in the network_validation object within the tokenization success webhook event.
Risk value definitions:
| Network Validation Response | Risk Values |
|---|
| Partial Match | Hard or Soft |
| No Match | Hard or Soft |
| Match Not Performed | Hard or Soft |
| Match Not Supported | Hard or Soft |
network_validation payload example:
{
"network_validation": {
"validation_provider_id": "1",
"name_validation": {
"name_match_status": 1,
"name_match_decision": 3,
"first_name_match_decision": 1,
"last_name_match_decision": 3
}
}
}
| ID | Description |
|---|
1 | Name match was performed |
2 | Name match was not performed |
3 | Name match not supported by provider |
4 | Client not configured for name match |
| ID | Description |
|---|
1 | Match |
2 | Partial match |
3 | No match |
Account Number Validation — ANV (Bank Account Only)
ANV is an optional feature for bank account (ACH) disbursements. It verifies the active status of the bank account number provided by the recipient against the issuing bank’s records.
ANV is performed during the verify call via the IngoPay API or the Embedded Account Capture SDK.
Risk value definitions:
| Value | Behavior |
|---|
| Hard | Reject the transaction or prompt re-entry (configurable max attempts) |
| Soft | Record the event and approve the transaction for the next step |
| Network Validation Response | Risk Values |
|---|
| No data or non-participating issuer | Hard or Soft |
| Positive data — non-participating issuer | Hard or Soft |
| Invalid account number | Hard (always) |
| Invalid routing number | Hard (always) |
Name on Account Validation — NAV (Bank Account Only)
NAV is an optional feature for bank account (ACH) disbursements. It verifies that the recipient’s name — and optionally their address — matches the account holder information held by the issuing bank.
Risk value definitions:
| Value | Behavior |
|---|
| Hard | Reject the transaction or prompt re-entry (configurable max attempts) |
| Soft | Record the event and approve the transaction for the next step |
| Network Validation Response | Risk Values |
|---|
| No data from issuer | Hard or Soft |
| Customer name or name and address no match | Hard or Soft |
| Customer or business name no match | Hard or Soft |
| Address no match | Hard or Soft |
PayPal Risk Verification Service
PayPal account verification, upon recipient consent, matches the recipient’s PayPal account data against client-provided recipient information for risk management purposes. Acceptance or rejection is based on your configurable matching criteria. If rejected, the recipient cannot reattempt verification with an alternate PayPal account.
Configurable verification fields:
| Field | Risk Values |
|---|
| First Name | Hard or Soft |
| Last Name | Hard or Soft |
| Address | Hard or Soft |
| City | Hard or Soft |
| State | Hard or Soft |
| Zip Code | Hard or Soft |
| Primary email match | Hard or Soft |
| Associated email match | Hard or Soft |
| Value | Behavior |
|---|
| Soft | Record event and approve transaction for next steps |
| Hard | Record event and prompt recipient to select an alternate payment method |
One-Time Authorization Code — OTAC
OTAC may be used as a primary, secondary, or dual authentication mechanism for Notify — Managed Parties programs. It delivers a time-limited code to the recipient via SMS or email, confirming they have access to the registered contact method.
Configurable OTAC options:
| Option | Description |
|---|
| Code length | Number of digits in the generated code |
| Code expiration | Minutes before the code expires |
| Allow same delivery method | Whether OTAC can be re-sent via the same delivery channel |
| Maximum code requests | Total OTACs that can be generated per session |
| Maximum unsuccessful attempts | Failed entry attempts before the session is terminated |
OFAC Screening
OFAC screening may be required depending on your program’s use case and integration. Ingo can perform OFAC checks for each recipient presented in the payment processing gateway. When configured, an OFAC check runs during the process call for any recipient whose last OFAC validation exceeds 30 days.
A suspended transaction is placed on hold pending review by Ingo’s Risk Services team. Results are delivered asynchronously via webhook. See Webhooks for the applicable event codes.
Transactional Velocity Limits
Velocity limits apply to all disbursement methods at the individual Customer Account Number level. Your Integration Manager will work with you to configure program-specific limits within the boundaries set by card networks, Ingo, and your sponsor bank.
All time periods are rolling except the daily limit, which resets at midnight Mountain Time.
| Velocity Limit |
|---|
| Maximum single transaction amount |
| Maximum daily total amount |
| Maximum rolling 7-day total amount |
| Maximum rolling 15-day total amount |
| Maximum rolling 30-day total amount |
| Maximum transactions per rolling 30-day period |
