Terminology
This page defines the records and concepts you work with in Alloy's Ongoing Monitoring solution. Terms are grouped by the records you send to Alloy, the decisioning Alloy runs on them, and how your team reviews the results.
Records
Entity
A record that represents a person or business, either a prospective applicant or an active customer.
Entities tie your data together across onboarding and ongoing monitoring. They're the records Alloy sends through a Journey, Workflow, or Events API request, and your Bank Accounts, Cards, and Transactions are linked to them. Each Entity has an Entity Token that starts with P- for a person or B- for a business, and Alloy strongly recommends assigning your own external_entity_id as well.
For more information, see Introduction to Entities.
Entity Group
A record that links multiple person and business Entities together, so Alloy can make decisions across all of them.
Each Entity Group has a type (business, merchant, joint_account, or membership) and one primary Entity, and each member Entity has a role in the group, such as beneficial_owner, director, or joint. Alloy creates an Entity Group automatically when you submit a multi-entity Journey Application. After onboarding, you keep the group up to date with the entity_group_created and entity_group_updated events.
Entity Groups replace the legacy Groups endpoints.
For more information, see Ongoing Monitoring with Entity Groups.
Bank Account
A record that represents an account your financial institution manages and monitors, such as a deposit, credit, brokerage, or loan account.
A Bank Account must be attached to at least one Entity, and an Entity can have multiple Bank Accounts. You create and update Bank Accounts with the bank_account_created and bank_account_updated events. Alloy assigns each Bank Account an account token that starts with A-, and you can also refer to it by your external_account_id.
Every Transaction you monitor in Alloy is tied to a Bank Account.
For more information, see Creating Entities and Accounts.
External Account
An account at another financial institution that your customer links to their profile for funding and disbursement.
Like a Bank Account, an External Account must be attached to an Entity, but it isn't normally used as the source of a Transaction. You send external_account_created when your customer links an account and external_account_updated when they unlink or relink it. A common use for these events is monitoring for potential account takeover.
For more information, see Linking Funding Accounts.
Card
A record that represents a card issued for one of your Bank Accounts.
Cards let Alloy tie card-level activity to the right Entity and Bank Account. You create a Card with the card_created event after its Entity and Bank Account exist, and you update it with card_updated. Alloy assigns each Card a token that starts with CARD-.
For more information, see Card Accounts.
Counterparty
A record that represents the other side of a Transaction: the person, business, or merchant on the account that isn't your financial institution's.
You describe the Counterparty in the counterparty object on each transaction event. The current schema splits the Counterparty into two parts:
- Identity: who the Counterparty is, such as a person, business, or merchant. Each identity is keyed by your
external_counterparty_identity_id, and you can link it to an existing Entity. Alloy never creates an Entity from a Counterparty identity. - Instrument: how the Counterparty was paid, such as a bank account, card, or digital wallet. Each instrument is keyed by your
external_instrument_id.
The legacy shape, which puts fields like account_number and external_counterparty_id directly on the counterparty object, is still accepted. You can't mix the two shapes in one request.
For more information, see Create an event.
Transaction
A record of money moving, or a request to move money, between one of your Bank Accounts and a Counterparty.
You create a Transaction by sending a transaction event, and you update it by sending another transaction event with the same external_transaction_id. Each Transaction is linked to an Entity, a Bank Account, and a Counterparty.
For more information, see Transaction Event Mapping.
Device
A record of a unique device that Alloy identified through device profiling, linked to the Entity or Counterparty that used it.
Alloy stores a Device record for each unique device ID that a device-profiling vendor returns, such as a TruValidate device_alias or a ThreatMetrix device_id. Each Device gets a Device Token, which shows when IDs from different vendors belong to the same device.
For more information, see Identifying Devices.
Decisioning
Event
Ongoing data, such as a new Entity, a Bank Account update, a Transaction, or a login, that you send through the Events API.
Each Event has an event_type and a data object. You can send an Event only to store its data in Alloy, which is a data-storing event. You can also map its event type to one or more Source Workflows so that Alloy evaluates it, which is a monitored event.
For more information, see Decisioning with Events.
Workflow
A container for the rules, data sources, and policy logic that Alloy runs against an Entity or Event to produce an Evaluation.
Each Workflow has a use case, such as Account Opening, Transaction Monitoring, or Ongoing Event Monitoring, and a scope of either a single Entity or your portfolio. Only Transaction Monitoring Workflows can evaluate transaction events, and only Ongoing Event Monitoring Workflows can evaluate most other event types. In ongoing monitoring, a Workflow that evaluates Events is called a Source Workflow.
For more information, see Workflow Types.
Source Workflow
A Workflow that monitors Events with your policy logic, either in real time or on a schedule.
A real-time Source Workflow runs an Evaluation each time you submit an Event whose type is mapped to it, and the Events API response includes that Evaluation. A Source Workflow can also have an Ongoing Journey attached, which runs depending on the Source Workflow's outcome.
For more information, see Decisioning with Events.
Portfolio Workflow
A Source Workflow that evaluates relevant Events on a schedule, instead of when each Event arrives.
Because it runs on a schedule, a Portfolio Workflow doesn't need an event mapping.
For more information, see Decisioning with Events.
Evaluation
The result of running data through a Workflow, including its outcome and any tags.
Every Event that a Source Workflow processes creates an Evaluation. For real-time Source Workflows, the Events API response returns each Evaluation in the evaluations array, with an evaluation_token that starts with L-. Depending on its outcome, an Evaluation can also lead to an Alert through an Ongoing Journey.
For more information, see View Evaluation.
Journey
A decisioning flow you build in the Alloy dashboard to run Workflows and actions in a set order.
When you submit data about one or more Entities to a Journey, Alloy creates a Journey Application to track that run. Journey Application tokens start with JA-.
For more information, see Journeys Overview.
Ongoing Journey
A Journey attached to a Source Workflow, which runs depending on the Source Workflow's outcome and creates an Alert.
Ongoing Journeys manage the state of alerted activity and let you run more Workflows or actions on one or more Events. The result of an Ongoing Journey is an Alert, which is a special type of Journey Application.
Note: If you're interested in Ongoing Journeys, contact your implementation team.
For more information, see Decisioning with Events.
Alert
A record of potentially risky activity that an Ongoing Journey creates, based on a Source Workflow's outcome.
Alerts flag activity such as fraud indicators, watchlist hits, or unusual transaction patterns for your team to review. Each Alert is linked to the Entity and Event data behind it. Alerts create Investigations, where your team reviews them.
For more information, see Decisioning with Events.
Review
Investigation
A reviewable record that holds Alerts for suspicious activity, along with the related Entities, Events, evidence, documents, and notes.
Alloy creates Investigations automatically from Alerts, or your team can create one manually. Each Investigation has a type, such as Fraud, and you can assign it to an agent. In Alert Review, your team reviews the Investigation's Alerts. If the activity needs deeper analysis, you can promote the Investigation to Case Review. You close an Investigation by reviewing it and recording an outcome.
For more information, see Investigations Events.
Case
A legacy record that grouped Evaluations that triggered case-generating rules for a single Entity.
Investigations replace Cases, and the Cases endpoints are deprecated in favor of Investigations. Use Investigations for any new integration. Case Review, a stage within an Investigation, is separate from the legacy Case record.
Updated 1 day ago