Product & Risk Configurations

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.

Maximum attempt limits apply to SaaS and Embedded Account Capture integrations only. Where a maximum attempts value appears below, it is enforced by the Ingo-hosted experience. Direct IngoPay API integrations do not enforce attempt counters — your application controls whether and how often a recipient may retry.

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

Configurable fields:

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.

Risk value definitions:

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

Configurable AVS responses:

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 is performed within the same card validation call that carries AVS and CVV — it is not a separate request. ANI results are included in the network_validation object within the tokenization success webhook event.

ANI is currently supported for Visa cards only. Mastercard support is planned. Because Ingo normalizes provider responses, no integration change will be required when it is added — see Status Codes.

How the risk value is applied: ANI does not carry an independent hard or soft outcome. The name match decision is evaluated as an input to the AVS hard/soft determination for the transaction, configured at the client level. The resulting behavior follows the AVS risk value definitions above. Configurable ANI responses:

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

ANI does not have its own attempt counter. A hard ANI result draws from the same AVS / CVV maximum attempts allowance rather than a separate ANI limit.

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
    }
  }
}

Name match status codes:

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

Name match decision codes:

ID	Description
`1`	Match
`2`	Partial match
`3`	No match

These are Ingo-normalized values. Integrate against them rather than against any network-specific response values.

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

Configurable ANV responses:

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

Configurable NAV responses:

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 and are evaluated at the individual Customer Account Number level — the recipient’s destination account — rather than in aggregate across your program. Your Integration Manager will work with you to configure program-specific limits within the boundaries set by card networks, Ingo, and your sponsor bank.

A field maximum in an API specification is not a program limit. The maximum value shown for an amount field in our API specifications is a format constraint — the largest value the field will accept. What your program is permitted to disburse is the configured limit, which is typically well below the specification ceiling. Confirm your configured values with your Integration Manager rather than inferring them from the specification.

Configured limits

Velocity Limit	Window	Code on breach
Single transaction amount range — minimum and maximum	Per transaction	`603` or `711` — see below
Maximum daily total amount	Resets at midnight Mountain Time	`712`
Maximum rolling 7-day total amount	Rolling 7 days	`713`
Maximum rolling 15-day total amount	Rolling 15 days	`716`
Maximum rolling 30-day total amount	Rolling 30 days	`714`
Maximum transactions per rolling 30-day period	Rolling 30 days	`715`

All periods are rolling except the daily limit, which resets at midnight Mountain Time.

Which code is returned for a single transaction breach depends on your integration. SaaS participants receive 603 — “transaction amount is outside your allowed range,” covering both the configured maximum and minimum. Non-SaaS integrations receive 711 — “exceeds single transaction amount limit.” Map whichever applies to your integration, and confirm which you should expect with your Integration Manager.604 is a separate funding control, returned when the amount exceeds your prefund balance or daily processing cap — not a velocity limit. See the Status Codes for full descriptions.

Enforcement behavior

Every request is evaluated against your configured limits in real time, and the outcome is deterministic. A request that breaches a limit is declined on that attempt, with the applicable code returned in the synchronous process response — there is no attempt counter that trips after a number of tries and no accumulating penalty. Where a cumulative limit is breached, that request and any subsequent request continue to be declined until the relevant window clears. Because the decline reason is returned synchronously with a specific code, you can surface a meaningful message to your user rather than a generic failure. Map each code above to the message you want your recipients or operators to see.

Validating limits before submission

You may choose to mirror your configured limits in your own system and validate before calling Ingo, so a user receives immediate feedback rather than waiting for a decline.

Single transaction range is the most practical to enforce pre-flight, because it is a static threshold requiring no history.
Cumulative limits can also be tracked on your side, but take more effort to maintain — you would accumulate per destination account and align to the midnight Mountain Time boundary for the daily limit.

Accumulate on `account_id`, not `customer_account_token`

If you track cumulative limits yourself, key your accumulation on account_id — the Ingo-assigned unique identifier for the disbursed-to account. It is returned in the account tokenization and payment webhook events. Persist it against your own records when you receive it.

Do not accumulate on customer_account_token. That token represents the customer and the account as a pair, so the same underlying account tokenized under a different customer identifier produces a different token. Ingo’s velocity counters accumulate against the account itself, so totals keyed on the token will undercount — your system may show a recipient as within their limit when they are not.This also means that sending a new customer identifier for a recipient does not reset their velocity counters. Cumulative limits follow the account, not the customer record.

The account_id inside the open banking object is a Finicity identifier and is not the same field — the spec notes it as distinct. Use the Ingo account_id (maxLength: 36) from the account and disbursement payloads.

Ingo’s ledger remains the authority for all cumulative limits. Treat any client-side check as a fast-fail for user experience, and continue to handle the response codes above as the final outcome.

Explore

Guides

Documentation

Trust & Compliance

Recipient Authentication (RA)

Recipient Verification Data Matching (RVDM)

Address Verification Service — AVS (Card Only)

Card Verification Value — CVV (Card Only)

Account Name Inquiry — ANI (Card Only)

Account Number Validation — ANV (Bank Account Only)

Name on Account Validation — NAV (Bank Account Only)

PayPal Risk Verification Service

One-Time Authorization Code — OTAC

OFAC Screening

Transactional Velocity Limits

Configured limits

Enforcement behavior

Validating limits before submission

Accumulate on `account_id`, not `customer_account_token`

​Recipient Authentication (RA)

​Recipient Verification Data Matching (RVDM)

​Address Verification Service — AVS (Card Only)

​Card Verification Value — CVV (Card Only)

​Account Name Inquiry — ANI (Card Only)

​Account Number Validation — ANV (Bank Account Only)

​Name on Account Validation — NAV (Bank Account Only)

​PayPal Risk Verification Service

​One-Time Authorization Code — OTAC

​OFAC Screening

​Transactional Velocity Limits

​Configured limits

​Enforcement behavior

​Validating limits before submission

​Accumulate on account_id, not customer_account_token

Recipient Authentication (RA)

Recipient Verification Data Matching (RVDM)

Address Verification Service — AVS (Card Only)

Card Verification Value — CVV (Card Only)

Account Name Inquiry — ANI (Card Only)

Account Number Validation — ANV (Bank Account Only)

Name on Account Validation — NAV (Bank Account Only)

PayPal Risk Verification Service

One-Time Authorization Code — OTAC

OFAC Screening

Transactional Velocity Limits

Configured limits

Enforcement behavior

Validating limits before submission

Accumulate on `account_id`, not `customer_account_token`