Multi-Level Attributes (MLAs) calculate historical metrics that can be used in Alloy workflow logic. They help identify patterns such as transaction activity, account balances, PII changes, linked-account activity, and shared identity elements.
Where to configure MLAs
Configure MLAs directly in Workflow Editor once the relevant first-party service is enabled and available in the account. The available MLAs and configuration options for each MLA depend on the selected service - for instance, the configuration for an MLA tied to Transaction History will be different from the Identity Element Velocity MLAs.
Open the workflow you want to edit.
Add or select the service that provides the historical data.
Add or edit a threshold or rule that uses an MLA.
Select Edit attribute to enter MLA focus mode.
Configure the formula, time window, scope, and available filters.
Select Done.
Save the workflow as a new version.
Workflow Editor displays an English description and footnotes for the configured MLA. Review this description before saving to confirm that the rule measures the intended behavior.
Current MLA services and types
Transaction History
Transaction History provides MLAs for historical transaction activity across Accounts associated with an Entity. It can also support activity measured from a Counterparty perspective.
Common MLA types include:
Monetary — aggregates transaction amounts, such as deposits or withdrawals.
Non-Monetary — counts or evaluates qualifying transactions without aggregating amount.
Counterparty — evaluates activity associated with a Counterparty.
Count of Days — counts the number of days on which a configured transaction condition was true.
Typical use cases include:
Sum of completed deposits within a lookback period
Count of qualifying transactions
Activity involving a specific Counterparty
Number of days on which transaction volume exceeded a threshold
Transaction filters may include geography, category, interaction point, MCC, minimum or maximum amount, transaction codes, Counterparty, return codes, user-initiated activity, transaction status, Account, source or destination Account, international status, processing method, entry mode, ISO message, and response code.
Account History
Account History provides historical account-level measurements.
Common MLA types include:
Account Balance — evaluates historical minimum or maximum balances.
Account Status — evaluates historical account status.
Account Changes — evaluates changes associated with an Account.
Typical use cases include:
Minimum or maximum Account Balance
Account age or Days on Books
Historical Account Status
Account activity within a relative time window
Entity History
Entity History provides historical Entity-level measurements for PII and BII activity.
Common MLA types include:
Distinct Changes of Entity PII — measures distinct PII values or changes during a period.
Distinct Count of Entity PII — counts distinct PII values.
Fraud Score — evaluates available historical fraud-score data.
Typical use cases include:
Recent email, phone, name, or address changes
Multiple distinct values for an identity element
Identity-element velocity within a lookback period
Historical fraud-related signals
Available PII elements and filters depend on the Entity History attribute and account configuration.
Entity Account History
Entity Account History provides Linked Accounts MLAs. These measure historical external-account linking activity for an Entity.
Example use case:
Count linked external accounts within a specified lookback period.
Identity Element Velocity
Identity Element Velocity (IEV) detects reuse of an identity element across different Entities. It can evaluate elements such as:
SSN
Email address
Phone number
First or last name
Full name
Date of birth
Address
Device alias
IP address
IEV can be configured to count:
Other Entities that have used the same identity element
Evaluations grouped by distinct SSNs
IEV is designed to answer:
How many other Entities have used this same identity element within the configured lookback period?
It does not count repeated applications from the same Entity as additional Entity velocity. If the goal is to count applications submitted by one Entity, use a different workflow design or a published-attribute and matrix-based approach.
IEV supports lookback periods of up to 90 days. The timeframe is measured relative to when the evaluation and identity element are saved in Alloy’s database.
Only one identity element can be targeted in a single IEV statement. To evaluate multiple elements, create separate statements or rules—for example, separate rules for SSN, phone number, and email address.
IEV uses the count of other Entities, so the current Entity is excluded from the count. The count of entities "seen" occurs after the evaluation ran.Thresholds must account for this behavior. For example, a rule requiring a value greater than 1 is met only when at least two other Entities have used the same element. When an Entity is first run, the count of times the PII was seen is 0 at that time. After the evaluation runs, the count increments to 1. The second time an Entity runs with the same PII, the count of times the PII was seen is 1 at that point.
How MLA thresholds work
An MLA produces a value that a workflow condition compares with a fixed threshold. For example:
Identity Element Velocity Multi-Level Attribute is greater than
1.
MLAs cannot currently be compared dynamically with another MLA or with a value calculated at runtime.
The exact meaning of a threshold depends on the MLA. Confirm the generated English description and footnotes in Workflow Editor, rather than relying only on the attribute’s display name.
Entity History PII calculations
Entity History supports distinct-count and distinct-change measurements.
For a distinct-change measurement, Alloy:
Retrieves values recorded during the configured time window.
Retrieves the latest value before the window.
Includes the value in the current request payload, including a value hydrated from the Entity profile.
Deduplicates the combined values.
Returns the resulting distinct count.
As a result, the returned value may not equal the number of update events. Repeated occurrences of the same value are deduplicated.
When multiple historical values have the same timestamp, Entity History applies its documented tie-breaking behavior. Phone-number hydration can also be affected by phone-type precedence, such as cell taking precedence over home.
PII storage requirements
Entity History can measure only PII events that Alloy has explicitly recorded. A value appearing on the current Entity profile does not, by itself, create a historical event.
When using the Events API, verify that the relevant PII is configured to be stored under Settings > Events > Event Mapping. If storage is disabled for the mapping, the event is unavailable for Entity History calculations.
Time windows
MLA time windows are relative to the evaluation or event timestamp. A window described as “1–2 hours” should not automatically be interpreted as the previous 120 rolling minutes.
When validating a result, compare:
Evaluation timestamp
Event or transaction timestamp
Configured lookback period
Interval boundaries
Timezone assumptions
Sandbox and testing
Identity Element Velocity and other complex MLAs are not supported by Sandbox Profiles and cannot be reliably coerced by assigning an MLA value to a Sandbox Profile. This is because Sandbox and Production data are not fully isolated within the same Alloy account. Sandbox API requests are processing-mode requests; the actual records—including Entities, Accounts, Transactions, Counterparties, and Devices—use the same underlying account data.
Consider these workarounds:
For testing Identity Element Velocity, Passing an input attribute such as
is_test: trueand building that into the Workflow can allow you to bypass the relevant velocity rule for test traffic.For testing Identity Element Velocity, using an allowlist for known test IP addresses.
For testing Identity Element Velocity, using unique test PII values to avoid triggering velocity logic.
- Use a separate Alloy test account when you need reliable environment and data isolation.
- If using one account, use collision-resistant external IDs or consistently prefix test IDs with
TEST-orSBX-. - Use entirely fake test Entities, identity elements, Accounts, and Transactions.
Comments
0 comments
Article is closed for comments.