How does the Risk-Based Approach work?
The Risk-Based Approach is not just about generating a single risk score. The primary goal is to determine the level of control to be applied by evaluating different risk signals related to the customer, transaction, and behavior together.
The process can generally be thought of in four stages.
1. Risk factors are identified
First, risk signals that could affect the customer or transaction are defined.
These may include:
- The customer's field of activity
- Transaction volume and frequency
- The country or location used
- The counterparty involved in the transaction
- Customer Risk Profile
- The account's historical behavior
- Device and IP information
- Sanctions or PEP results
- Transaction channel
- The ownership structure of the customer or company
A single factor is often not enough. What matters is how these signals combine to form a risk profile.
For example, using a new device might not be a significant risk on its own. However, if a new device, a different location, a new recipient, and a transfer amount much higher than the customer's normal behavior are observed at the same time, the transaction may be evaluated differently.
2. The context of the customer and transaction is evaluated
The same transaction does not mean the same thing for every customer.
For example, a transfer of 200,000 TL might be normal for a corporate customer with high transaction volumes. The same amount might require more scrutiny on a newly opened individual account that has only conducted low-volume transactions so far.
This is exactly where the Risk-Based Approach comes into play.
The system does not just look at:
"Was the amount limit exceeded?"
It also evaluates the following:
- Is this transaction normal for this customer?
- Have they shown similar behavior before?
- Is a new device being used?
- Is the transaction time typical?
- Has a new recipient been defined?
- Is there a sudden change in transaction frequency?
- Is the counterparty linked to other risky accounts?
Therefore, in risk assessment, not only the transaction itself but also the context in which it occurs is important.
In FATF's Risk-Based Approach, the core logic is also to identify risks and ensure that the measures applied are proportionate to the identified level of risk.
3. The risk level is determined
The collected risk signals are used to assess the risk level of the customer or event.
For example:
- Use of a new device
- Unusual location
- A high number of transactions in a short period
- New recipient
- Sanctions or PEP match
- Significant deviation from the customer's historical behavior
signals like these can be evaluated individually or together.
The key point here is that a high risk score does not directly mean fraud or crime.
The risk score is more of a decision support element that helps answer the question:
"Should this transaction or customer be investigated more closely?"
4. Actions are determined based on the risk level
The final stage of the Risk-Based Approach is not just to detect risk, but to determine the appropriate action for that risk.
While a low-risk transaction can proceed normally, for a higher-risk event, different controls can be applied, such as:
- Additional verification
- Alert generation
- Case creation
- Manual review
- Ongoing Monitoring
- Enhanced Due Diligence
This ensures that not every customer and transaction has to go through the same investigation process.
Should every high-risk customer be rejected?
No.
This is one of the most common misconceptions about the Risk-Based Approach.
High risk does not mean:
"We absolutely cannot work with this customer."
It indicates that additional controls, such as further investigation, extra verification, more frequent monitoring, or Enhanced Due Diligence, may be required.
The goal of the approach is not to eliminate every risky customer relationship, but to properly identify and manage risk.
Therefore, a balanced relationship must be established between the risk level and the control to be applied.
What is the difference between the Risk-Based Approach and the Rule-Based Approach?
The two approaches are not alternatives to each other.
Rule-Based Approach operates based on predefined, explicit conditions.
For example:
Generate an alert if the total transfer amount in the last 24 hours is over 100,000 TL.
This rule is clear and easy to apply. However, looking only at this rule might cause the customer's historical behavior or the context of the transaction to be overlooked.
Risk-Based Approach, on the other hand, looks at the same transaction from a broader perspective:
- How long has the account been open?
- What is the customer's normal transaction volume?
- Has the device changed?
- Has the location changed?
- Is there an increase in transaction frequency?
- Is the recipient being used for the first time?
- Are there other risk signals?
Therefore, in a strong risk management framework, a Rule Engine and risk-based assessment can be used together.
While rules capture specific behaviors, risk assessment helps understand what those behaviors mean for the customer.
Why must risk be continuously updated?
A customer's risk level should not be determined solely during onboarding and left unchanged for years.
This is because customer behavior can change over time.
For example:
- Transaction volume may increase.
- They may start transacting with different countries.
- Their device or location habits may change.
- The company's ownership structure may change.
- A new sanctions or PEP match may occur.
- Unusual changes in transaction frequency may be observed.
Therefore, the Risk-Based Approach must be considered alongside Ongoing Monitoring.
The customer's risk level can be re-evaluated as new information and behavioral changes emerge.
How does Truvali support the Risk-Based Approach process?
Truvali's contribution here is transforming risk assessment from a static label created solely during onboarding into a framework that operates at the transaction and event level.
Real-Time Risk Scoring
Truvali does not treat user risk as a fixed score assigned only during onboarding.
Transaction patterns, behavioral indicators, device, IP, network signals, and other risk factors can be included in the evaluation. As behavior changes, the risk score can be recalculated.
Financial and non-financial events are evaluated together
Risk does not only arise from money transfers.
Non-financial events, such as using a new device, changing IPs, updating account information, logging in from a different location, or adding a new recipient, can also be evaluated alongside financial activity.
Within Truvali's Event Score Engine framework, different signals such as transaction history, user behavior, device & IP, network relationships, watchlist results, and Customer Risk Profile can be included in the same evaluation.
Dynamic Rule & Scenario Engine
Every institution's risk appetite and what it considers normal user behavior is different.
In Truvali, institutions can create their own risk scenarios and include different fields in Rule Engine conditions.
Custom time windows, such as the last 30 minutes, last 24 hours, or last 15 transactions, can be used.
With Cross-Entity Checking, senders, recipients, accounts sharing IPs or devices, and blacklist results can be checked within the same scenario.
Different actions based on risk outcomes
In Truvali, the outcome of a risk assessment does not have to remain just a score displayed on a screen.
Depending on the scenario defined by the institution:
- The transaction can proceed.
- Additional verification can be applied.
- An alert can be generated.
- A case can be opened.
- A manual review can be initiated.
- Actions can be transmitted to the institution's core system via callback.
This ensures that not every risk signal leads to the same outcome; actions can be shaped according to the institution's risk policy and the context of the event.
Frequently Asked Questions
Is the Risk-Based Approach only used for AML?
No. In addition to AML/CFT processes, different controls can be applied based on the risk level in fraud, Customer Risk Scoring, Transaction Monitoring, and KYC/KYB processes.
Does a high risk score indicate that the customer is a criminal?
No. A high risk score indicates that the customer or transaction requires a more detailed evaluation. It is not, on its own, evidence of crime or violation.
Can the Risk-Based Approach and Transaction Monitoring work together?
Yes. While Transaction Monitoring tracks transaction activity, the Risk-Based Approach ensures that these activities are evaluated alongside the customer profile, historical behavior, and other risk signals.
Is the risk score static?
No. As customer behavior, transaction history, location, device, or other risk factors change, the risk assessment can be performed again.