Overview
- Batch (ICL) limits
- Limits the maximum credit, debit, or both, amounts for a single batch (ICL) of transactions. If a batch (ICL) limit is exceeded, the batch (ICL) can be rejected or put into a suspended state based on the configuration of the batch (ICL) limit.
- Transaction limits
- Limits the maximum credit, debit, or both, amounts for a single transaction. If a transaction limit is exceeded, the transaction can be rejected and marked as overrideable based on the configuration of the transaction limit. Transaction limits also support a velocity span that within a specified time a maximum limit is applied to the credit and debit amounts or counts. The maximum timeframe for a velocity limit is 24 hours or 1440 minutes. Within the specified interval, if the total amount or number of transactions is exceeded then the transaction can be rejected.
- Exposure limit monitors
- Limit the overall credit, debit, or both, totals of transactions sent by a participant. Monitors keep a running total of the amount sent for each business day for the participant. Risk Management allows the creation of credit or debit limits at both the batch and transaction level. The monitoring limit can be set for either a single business day or across multiple business days. If the total amount of all batches (ICLs) received for the configured time period exceeds the designated limit for the participant, an error is generated. Subsequent transactions are rejected and can be held for review.
- Authorization filters
- Only transactions that match the filter criteria are accepted. When a transaction does not match, the transaction is rejected or marked as reviewable, based on the configuration of the filter.
- Blocking filters
- Transactions that match the filter are rejected and cannot be reviewed.
- Positive pay
- Only transactions that have a corresponding positive pay record are accepted. When a transaction for an account that requires positive pay checking is received and a matching positive pay record is not found, the transaction is rejected and marked as reviewable based on the configuration of the filter.
- Stop pay
- Transactions that match a stop pay record are rejected and cannot be reviewed.
As work is loaded into the FTM database, Transaction Server events notify the Risk Management engine of incoming batches (ICLs) that need to be monitored or checked by the authorization services. Transactions and batches (ICLs) that are rejected and overrideable or reviewable, are held or suspended until an operator reviews them and either accepts, rejects, or retries them with higher limits or more funds available. Operators use the Risk Management user interface to do this review or to modify limits.
- AUTH_CHECKED
- Indicates that the batch (ICL) processed the authorization checks that were configured to run. Transactions might be held for review.
- AUTH_REVIEWED
- Indicates that the batch (ICL) processed the authorization checks and no transactions are being held for review.
- ACTIVITY_MONITORED
- Indicates that the batch (ICL) processed the exposure limit monitor checks and limit checks that were configured to run. Transactions or batches (ICLs) might be suspended and eligible for review.
- RISK_REVIEWED
- Indicates that the batch (ICL) processed the risk monitoring and limit checks and the batch (ICL), or any of the transactions within the batch (ICL), are not awaiting review.
A browser-based administrative console allows administrators and users to access the component without special client software. Preferences for time zones, dates, and language are configurable, enabling users to reside in multiple locations or geographical areas from the location of the component installation. Console features are provided for typical user and component administration. The typical user can view the status of exposure limit monitors and can be given permission to accept or reject batches (ICLs) and transactions that failed a risk check. The administrator sets up users, grants permissions, and configures runtime properties.
Risk Management, by using WebSphere® Application Server, can be deployed to a single computer or to multiple computers. Multiple computers provide workload handling and high availability. All instances share message queues and database.