Risk Management authorization checking

Use the account rules link on the partner details page to define risk authorization checking for the accounts that are associated with a receiving participant. For each account, the user can enable authorization filter checking, positive pay checking, or both. If an account is not enabled for authorization checks, the Risk Management engine does not do the authorization filter checks when a transaction for that account is received. Similarly, the Risk Management engine does not do the positive pay checks for a transaction unless the corresponding account is enabled for positive pay checking.

Blocking filter and stop pay checks are done unless no blocking filters or stop pay records are defined for the account number.

When the Risk Management engine receives a performAuthorizationCheck message for an incoming batch (ICL), it does the risk checks in the following order:
  • Blocking filter
  • Authorization filter
  • Stop pay
  • Positive pay
A transaction that fails any of the checks is rejected, regardless of the rejection level indicated by the system error code assigned to the check. For example, if the error code indicates that the batch (ICL) is to be rejected, only the transaction that fails the check is rejected. Error codes also control if the authorization filter and positive pay failures are sent to an operator for review. Authorization filter and positive pay failures can be reviewed if one of the following conditions is true.
  • The error code that is associated with the failure is defined as overridable.
  • The account rules page is used to override the error code and define the error as reviewable for this participant and account.

The Risk Management engine continues risk checking until either a check fails or all of the checks complete successfully. When a risk check fails, the engine does not do any remaining risk checks for the transaction. If a risk review operator later reviews and accepts the transaction, the Risk Management engine resumes risk checking by doing the remaining checks for the transaction. Therefore, an operator might approve an authorization filter failure for a transaction, and then see that the transaction is redisplayed on the review page because it failed positive pay checking.

After all of the transactions for a batch (ICL) are checked, the time that the risk check finished is stored as a timestamp value in the AUTH_CHECKED column in the PRESENTMENT table. The check completion timestamp is stored even if some transactions failed the check and are marked as reviewable. After an operator reviews all of the transactions that need to be reviewed for a batch (ICL), the time that the review was completed is stored as a timestamp value in the AUTH_REVIEWED column in the PRESENTMENT table.