Risk levels are the customizable building block for defining your organization's risk appetite: they translate numerical risk scores into human-readable categories such as Low, Medium, or High. In the Console, risk scores range from 0 to 100, and each risk level owns a contiguous slice of that range.

Each risk level is defined by a score interval, and the intervals for all levels together span the full 0-100 range. To classify a score, find the interval that contains it. For example, if Medium owns the 35-56 interval, a computed risk score of 40 falls inside that interval and is therefore classified as Medium.

Going the other direction, locate the score interval that contains a given risk score; the level corresponding to that interval is the risk level. A risk score of 20 falls within a 19-35 interval, which corresponds to a Low risk level.

The Risk Levels page: each level's score range, adjusted with sliders.

Version History for Risk Levels, with each version's comment, timestamp, and author.

If your organization prefers different labels than Low/Medium/High/Very High, go to Settings > Risk Scoring and scroll to the Risk Levels Alias section. Enter an alias next to the corresponding risk level and click Update. The new label propagates across the platform. This is useful if you only want to work with three of the five levels; for example, renaming Very High to a label like Prohibited or Blocked to communicate its specific usage.

Flagright combines several risk scores into an overall assessment. Each is produced by a configurable, weighted formula, so the underlying algorithm can be tuned to your organization's risk model.

KRS is the risk score of a customer's profile. It is a weighted combination of the risk scores of the customer's individual risk factors, divided by the sum of those factors' weights. KRS is calculated the moment a user is created (typically at onboarding, over the API), and it's recalculated automatically on every subsequent user event. For example, if the customer updates their name, email, or residence a few days later, KRS is recalculated to reflect the change.

For an Indian national aged 30-40 residing in Dubai with the values above, KRS = ((44 × 0.5) + (54 × 0.3) + (76 × 0.2)) ÷ (0.5 + 0.3 + 0.2) = 53.4, placing the customer in the Medium risk category.

TRS is the risk score of a given transaction or action, calculated the same way as KRS: a weighted combination of the transaction's risk factors. Once a customer starts transacting, every transaction gets its own TRS; a customer's profile shows the average TRS across all of their transactions.

Each risk factor has a corresponding weight that determines its influence on the final TRS, following the same weighted-average structure as KRS. In practice, transaction-level factors commonly include the transaction type (deposit, withdrawal, internal transfer), the currency involved, the payment method (cash is typically scored riskier than ACH, wire, or card), and the origin and destination country.

A transaction's TRS breakdown, showing each contributing risk factor, its value, weight, and risk level.

CRA is the overall, dynamic risk assessment for a customer: a composite of KRS and average TRS. By default it's a simple average of the two; a custom weighting can be configured instead (for example, 90% KRS / 10% average TRS), as long as the weights sum to 1.

CRA is best understood as a behavioral risk profile layered on top of the profile-based KRS: a customer might onboard as Medium risk based on their KYC profile, but if their ongoing transaction behavior looks increasingly risky, their average TRS pulls their CRA up toward High over time, and vice versa. This is also what connects risk scoring to transaction monitoring: a customer's current risk level can drive different rule thresholds, so riskier customers get scrutinized at lower transaction amounts (see Section 03).

Once your risk factors are configured with risk levels and weights, each factor's inputted risk level is quantified into a score (the average of that level's lower and upper bound), and CRA aggregates all of it. To see a customer's calculated CRA, KRS, and average TRS, open their profile on the Users page.

A user's profile showing CRA risk level (with lock control), KYC risk score, and average TRS risk score.

Risk levels aren't just descriptive labels; they can directly change how strictly a rule is applied. Pairing a customer's or transaction's current risk level with a rule's thresholds is what Flagright calls risk-based monitoring: the riskier a customer or transaction is, the lower the amount it takes to trigger scrutiny.

When configuring a rule's parameters, the Risk-Based Thresholds tab lets you set a separate transaction amount threshold (per currency) for each risk level from Very Low through Very High, plus the action to take if the rule is hit at that level. This means the same rule can, for example, flag a Very High risk customer at a much lower transaction amount than a Very Low risk one.

Risk-based thresholds: enabling CRA-based logic, then setting a transaction amount threshold and rule action per risk level.

Risk factors are the individual parameters, such as Country of Nationality, transaction type, or a custom field, that feed into a user's or transaction's overall risk score. Consumer users, business users, and transactions each have their own separate default list of risk factors, and default and custom risk factors can run side by side.

Before configuring individual risk factors, decide which risk scoring layers your organization uses. Go to Settings > Risk Scoring in the Console to control this.

Settings > Risk Scoring: algorithm type, the CRA toggle, and the CRA algorithm choice.

Every risk factor has a default risk level: the risk level automatically assigned to any value that has not been explicitly configured. For example, if the Country of Nationality risk factor has no risk level assigned to a specific country, that country will be scored using the factor's default risk level.

Some organizations don't want missing or unmapped data to carry meaningful risk on its own. There are two ways to reduce that impact, and they can be combined for a full effect:

A consumer risk factor (Country of Residence) with its weight, default risk level, and status.

Weights range from 0 (no impact) to 1 (maximum impact) and determine how much influence a factor has on the overall score; if no weight is assigned, the system defaults it to 1. The system doesn't enforce a total, but as a practical convention, most organizations make the weights across all factors in a category add up to 1: it makes the framework easier to track and reason about than, say, a total of 8.

Some factors, like customer age, are naturally banded rather than categorical. For these, you configure numeric ranges with sliders and assign each range its own risk level, rather than picking from a fixed list of values. Each range has a lower bound and an upper bound; a value that falls exactly on a boundary belongs to the higher range. For example, if you set 0-21 as Low, 21-45 as High, and 45-80 as Medium, a user aged exactly 45 falls into the Medium range, not High, because the boundary value belongs to the range that starts at 45.

A range-type risk factor (Customer Age) with risk levels assigned to numeric bands.

For country-based factors, you can select countries individually, or paste in a semicolon-separated list of ISO 2-letter country codes to bulk-assign many countries to a risk level at once, useful when applying a published country risk list in one pass.

Country of Nationality with risk levels assigned across the full country list.

As a starting point for country risk, many organizations use the FATF grey list and black list (countries under increased monitoring or subject to a call for action, revisited at each FATF plenary meeting), alongside published indices such as the Basel AML Index. A common approach is to mark FATF grey- and black-listed countries as High or Very High risk, and to revisit the mapping periodically as these lists are updated.

For countries you consider unacceptable risk outright, commonly heavily sanctioned jurisdictions, you can mark them Very High and enable the overriding risk factor option (see Section 06), so that KRS and CRA are forced to 100 whenever a customer's nationality or residence matches, regardless of any other factor.

Default and custom risk factors can be activated simultaneously across Consumer Users, Business Users, and Transactions. When both are in use, the final risk score reflects the values and weights of all activated risk factors. A full breakdown of any transaction's risk score is available via the (i) button in the Transaction view; the same button on a user's page shows the KRS/CRA breakdown.

Beyond the country, age, employment, and funds-source factors covered above, these are commonly used across the three categories:

For large numbers of inputs beyond countries, prepare a comma-separated list of values and copy it. In the Console, paste the list into the input section; Flagright automatically separates the values. Choose the risk level to apply and click Save.

For example, to bulk-assign several employment statuses as High risk, copy the following and paste it into the Value field:

After pasting, each value appears as a separate tag. Select High as the risk level and click Add, then Save.

If you already classify KYC or CRA risk levels in a legacy or third-party onboarding system, you can send those levels directly into Flagright via the API rather than reclassifying risk in multiple platforms. Flagright doesn't require you to abandon a framework you're already happy with. This keeps a single, holistic view of customer and transaction risk and streamlines reporting.

Beyond the default library, you can build fully custom risk factors from scratch, no coding required, by combining aggregate variables (transaction counts, sums, or change frequencies) with entity variables (countries, user attributes) into your own risk logic.

Basic details step when creating a custom risk factor: name, description, default risk level, and default risk weight.

A common use of an overriding custom factor is a sanctions screening match. Add a Sanctions Match variable, then define two conditions: when the match is true, assign Very High risk with a weight of 1 and enable the overriding risk factor option, so that whenever this condition is met it overrides KRS and CRA outright; the transaction-side TRS is unaffected. When the match is false (the vast majority of customers), assign a score of 0, and optionally tick the option to exclude this factor from the calculation entirely for those customers, so it doesn't dilute their score. Each condition can be given a logic name, for example, "Sanctions match true", which is exactly what appears, labeled, in that customer's risk breakdown.

This example scores a consumer based on how large their typical transaction is. In Risk Factor Configuration, add one aggregate variable: field to aggregate = Transaction Amount, function = Average, entity = Sender, time period = last 90 days. Then define logic conditions comparing that average against fixed thresholds that reflect your organization's risk appetite.

The Average Transaction Value example above shows the core pattern: one aggregate variable, scored against fixed threshold bands. The same pattern applies to behavioral signals, just with a different field and function. For example, instead of averaging transaction amounts, you can count how many times a user has changed their email address in the last 90 days.

The aggregation variable modal, where you set variable type, aggregate field, function, and time window.

This example flags a transaction as high risk when it is sent to a country on your high-risk list and that country is not in the customer's declared expected transaction countries, a common pattern for detecting undisclosed cross-border activity.

Not every risk factor is relevant to every customer or transaction, and some risk indicators are severe enough that they should outweigh everything else. Flagright supports both cases.

Some risk factors only matter when a specific condition is true. For example, a PEP status factor should increase the customer's score when PEP is confirmed, but shouldn't lower or affect the score at all when the customer is not a PEP. Flagright gives you two options for handling this: assign a score of 0 for that value (the factor stays in the calculation but contributes nothing), or tick the Exclude from calculation option so the factor is completely removed from the weighted average for that customer. The difference matters: a score of 0 still dilutes the average slightly because it adds a zero-weighted term, while excluding it removes it entirely.

Selecting the "overriding risk factor" checkbox in a KRS factor's configuration means that when its condition is met, it takes precedence over the customer's other risk factors. If multiple overriding KRS factors apply, their weighted average determines the final score and level. The resulting KRS becomes the new CRA, and the CRA is then locked.

A consumer risk factor (Country of Residence) with the Override checkbox available per value, scoped to KRS.

The same override checkbox is available for TRS risk factors, but scoped to the transaction rather than the customer. An overriding TRS factor changes that transaction's TRS, and also updates the customer's CRA to match, locking it in place, the same way an overriding KRS factor does. When multiple overriding TRS factors apply to one transaction, their weighted average determines that transaction's final TRS, the same way KRS overrides combine.

A transaction risk factor (Destination Country) with the same Override checkbox, scoped to TRS.

User tags are custom attributes that enrich user profiles and can feed directly into risk scoring, segmentation, and rule logic, particularly useful when a parameter isn't available from source systems but is still relevant for a risk decision (for example, tagging a user with a Financial Risk level of High, Medium, or Low).

Settings > Users: status locks and a custom Enum tag (Financial Risk).

Once a tag exists, assign it to a user by opening their profile, clicking Edit Tags, selecting the tag key, and choosing the appropriate value. Tags can also be passed in programmatically via the API. When creating or updating a consumer user, include a userTags array in the JSON body with the tag key and value:

The same Settings > Users screen offers two related locks: KYC/User Status Lock prevents further edits to the KYC status and user status fields, and PEP Status Lock prevents further edits to PEP status, once those have been confirmed and shouldn't be casually changed. Note that updating a user's PEP status, for example, as the outcome of an alert investigation, automatically triggers a risk scoring recalculation for that customer.

Approval workflows add a review step to changes made to risk levels and risk factors, ensuring only authorized personnel can approve modifications before they take effect.

Settings > Risk Scoring: Risk Level Approval and Risk Factor Approval workflow selection.

Beyond a single approver, you can build multi-level approval chains. For example, a change proposed by an analyst goes first to an approver, then to a manager, before it takes effect. You pick a role for each level when building the workflow, and can attach the finished workflow specifically to risk level overrides, to risk factor changes, or to both.

Once configured, any change to risk levels or risk factors, including a manual risk level override, generates a notification for the assigned approver(s), who can approve or deny it before it takes effect. This provides oversight and control, and helps satisfy regulatory requirements for reviewed and authorized changes.

Risk score recalculations can be triggered manually or scheduled to run automatically, keeping Customer Risk Assessments current as your configuration or a customer's circumstances change.

Changing a risk factor's configuration only applies going forward; it doesn't retroactively rescore your entire existing user base. Before committing a broad change, use the Simulator to test it against a sample of users (or the full base) and preview the impact before anything goes live.

KRS/CRA and TRS can be enabled independently in the Console under Settings > Risk Scoring. The key settings on this page are:

If you don't yet have a transaction risk scoring framework in place, you can start with KRS and CRA only and add TRS later.

Go to Settings > Risk Scoring and use the Rerun Now button in the CRA section. This recalculates KYC Risk Scores (KRS) and Customer Risk Assessments (CRA) for the affected population; Transaction Risk Scores (TRS) are not affected and remain unchanged.

Manual re-runs are a limited resource: your organization has a re-run allowance. Use this sparingly, and only when a configuration change genuinely requires a full recalculation rather than waiting for the next scheduled batch run. If you need more re-runs than your current limit allows, contact your Customer Success Manager to request an increase.

You can also schedule automated re-runs that only execute when your risk configuration has actually changed, useful for factors that drift on their own over time, such as customer age, even when a customer makes no API calls.

Individual customers can also be automatically rescored when a blacklist or whitelist change affects them, or when a Suspicious Activity Report (SAR) is filed and your risk factors include SAR-related parameters, keeping assessments current with compliance events in real time.

Settings > Risk Scoring: re-run trigger settings for SAR filings and list changes.

Normally, any API request that touches a user triggers a recalculation. If you're feeding risk levels in from an external onboarding or legacy system and want tighter control over exactly when Flagright recalculates, you can enable risk scoring while suppressing automatic recalculation on every API call, and instead trigger recalculation manually or on a fixed schedule, for example, quarterly.

You can set an organization-wide default expiry period for manual CRA overrides (for example, 365 days), so that an analyst's override automatically expires unless a different expiry, or a permanent lock, is explicitly chosen at the time of the override.

Key behaviors to understand:

While a re-run is processing, the Rerun button on the Settings > Risk Scoring page is disabled to prevent duplicate runs. You can monitor real-time progress on this same page: a progress indicator shows recalculation status, and the button re-enables when it finishes. Re-run allowances are limited and set by the super admin for your organization. Use them sparingly, only when a configuration change genuinely requires a full recalculation. If you need additional re-runs beyond your current limit, contact your Customer Success Manager to request an increase. To review history, click the CRA info icon on a user's profile to see both current and previous risk score calculations.

The CRA score modal, showing the formula and the full history of CRA and TRS score changes over time.

Any risk-relevant change that doesn't originate from an API call, such as a manual override made in the Console, an automatic lock, a recalculation triggered by a SAR filing or a list update, or a PEP status change, has no API response for your system to read it from. Webhooks close that gap by pushing the change to your own systems as it happens.

Go to Settings > Developers to add a webhook endpoint: a URL that your own system exposes to receive Flagright's requests.

A CRA_RISK_LEVEL_UPDATED webhook, for example, arrives as a POST request to your endpoint with a JSON body along these lines:

Field names and values follow the same conventions as the rest of the API; consult the webhooks reference for the full payload schema and the complete list of event types.