.png)
Using Decisions for Risk Mitigation
Overview: This implementation resource outlines decision actions including Block Authorization, Hold for Manual Review, and Send Funds to Reserve.
What are Decisions?
Decisions are a configuration of rules allowing Facilitators or Referrers to set specific risk criteria, such as Card Verification Value (CVV) Result or Bank Account Authentication, to determine the automated action that should occur to a transaction or entity.
Automating manual risk decisions & actions, providing greater protection from risk liabilities, and ensuring your portfolio adheres to your preferred risk standards and guidelines make Decisions an invaluable tool.
The robust and multi-layered logic of Decisions provides granular configuration settings, allowing you to apply compliance standards with precision and ease.
Decision configurations are made up of Decision Rules, Decision Actions, and Conditional Rules.
Decision Rules - The entity or transaction behavior that must occur to trigger the Decision Action.
Decision Actions - The action that takes place after the Decision Rule has been triggered.
Conditional Rules - The additional custom criteria applied to the Decision Rule trigger.
Setting up Decision Rules & Actions
Navigate to the Decisions tab by following the steps below:
Setting up Conditional Rules
Once you’ve set up your core Decision Rule and Action, you can add additional parameters or criteria using Conditional Rules. Read more about Conditional Rules below.
Note: You cannot begin a conditional rule using the and logic. This is a known platform issue that is currently being addressed.
To add additional criteria to the Decision Rule you’re setting up or another existing Decision Rule, follow the steps below:
Decision Rules
Decision Rules refer to the specified risk criteria required to trigger a Decision Action.
Decision Rule Logic - if
Both Decision Rules and Conditional Rules utilize an if, then logic that determines when the Decision Action takes place.
5 Rule Types provide their own sets of specific Decision Rules:
Consumer Transaction Risk - Risk behaviors related to specific consumer transactions.
Merchant Transaction Risk - Risk behaviors related to an overall Merchant.
Boarding - Risk behaviors related to Merchant boarding.
Refunds - Risk behaviors related to Merchant refund issuance.
Watchlists - Risk behaviors related to OFAC watchlist and other custom watchlist configurations.
Example
Decision Rule: Merchant Transaction Risk > Inactive Merchant
“If an inactive Merchant attempts a transaction, [then] Block Authorization.”
See the content below for a complete list of all Decision Rules and their related Rule Types.
Decision Actions
Decision Actions refer to the specific automated process that should take place when the specific criteria are met.
Decision Action Logic - then
Decision Actions require Decision Rule, (if) to trigger one of the available actions (then).
Example: “If an inactive Merchant attempts a transaction, [then] Block Authorization.”
3 available Actions can take place when a Decision Rule is triggered:
Block Authorization - Changes a high-risk transaction’s status to
Failedto mitigate transaction risk.Send Funds to Reserve - Creates a Reserve on a specified amount of funds to allow transaction risk events and all other applicable rule types to be vetted before disbursing the funds.
Hold for Manual Review - Creates a Hold that either prevents a high-risk Merchant from boarding or a transaction from reaching a
CapturedorSettledstatus.
Example
Decision Action: Take this ACTION > Block Authorization
“If an inactive Merchant attempts a transaction, [then] Block Authorization.”
See the content below for information about Decision Actions.
Action | Description | Applicable Rule Types |
|---|---|---|
Block Authorization | Indicates that the specific conditions have not been met and the transaction status will be Block Authorization is specific to transaction processing. |
|
Send Funds to Reserve | Indicates that a merchant has been flagged above a specific threshold or percentage and will automatically create a reserve. |
|
Hold For Manual Review | Indicates unclear or insufficient data submitted from Merchants during boarding or flagged transactions processed or attempted by the Merchant. |
|
Block Authorization
The platform validates the integrity of responses it receives from an issuer. If the response criteria don’t meet the platform-defined criteria, a Reverse Authorization will be issued to reject it from processing.
This event occurs within a second of the transaction approval and the original transaction will be marked as “Failed”. In this event, you will be able to see in the Transaction Stream that the transaction was reversed.
Note: This decision is primarily used for AVS and CVV validation.
If you are not able to provide AVS data (zip and address1 data), please reach out to your Relationship Manager to set a timeline on implementation.
Hold for Manual Review
This will prevent the merchant from boarding and send an alert to Platform Underwriting to review the merchant account. Upon review, additional documentation or clarification may be requested from the merchant to remove the hold for a transaction or boarding.
Note: A held transaction will not Capture or Settle.
Platform Risk will review transactions and may request supporting documentation or information to allow that transaction to settle.
Transaction amounts that severely exceed the estimated average transaction amount listed by the merchant in their Signup Form, or suspicious activity; such as excessively large transaction volume not previously identified.
Our Risk team will review a transaction and may request supporting documentation or information to allow that transaction to settle.
Send Funds to Reserve
Reserves can be leveraged in instances where suspected money laundering, fraudulent activity or prohibited business activities are occurring.
Reserved merchants indicate the merchant’s ability to transact, but not fund any of the transactions in their Available Balance.
This is typically applied when a merchant is flagged above a certain threshold, such as a TIN match without at least a 50% owner authentication match. Platform Underwriting may request additional information to qualify the merchant (depending on their internal verification).
Note: A reserved transaction will Capture and Settle.
That reserved transaction, however, will not be funded until reviewed by Platform Risk.
Conditional Rules
Conditional Rules refer to the rule logic applied as extra criteria aside from the primary Decision Rule, to configure a more precise final Decision Rule logic.
Conditional Rule Logic - and if
Conditional Rules are linked to primary Decision Rules using an and if logic.
Conditional Rules use the same if, then logic as standard Decision Rules. However, it does not offer an additional than logic, because you’ve already configured it with a Decision Action.
Example
Decision Rule: Merchant Transaction Risk > Number of Times Merchant/CC Number(s) Fail
Decision Action: Take this ACTION > Block Authorization
Conditional Rule: Consumer Transaction Risk > Transaction Fraud Score
“If merchant unsuccessfully charges the same card more than 2 times and if their Transaction Fraud Score is below 85, [then] Block Authorization.”