Skip to main content
Hidden Use the Real-Time Decisioning Data Studio to define and manage lists.

Managing lists

A list is a data table stored on the Real-Time Decisioning platform that maintains profile information about users, accounts, and other entities. This data is often used in combination with the transactional event data sent to the system for the development of features and business rules. You can use lists to store entities that should be blocked, suspended, automatically approved, or applied with other specific treatments. For example, you can use lists to store phone numbers, card numbers, and IP addresses that you want to block. You can also use lists to store accounts that are placed in a temporary hold status until a future time. To use a list, you must first create a feature that performs a lookup on the list with given input parameters. The lookup will be performed when the feature’s output is calculated as part of a rule evaluation. The platform supports two types of lists: system lists and custom lists. There is no limit to the size of the lists.

System lists

The platform provides two system lists: Blocklist and Allowlist. These lists have fixed schemas. Both lists require two keys for each entry:
  • Entity type: The type of entity, such as email or bin_number
  • Entity value: The value of the entity that should be stored in the list, such as johndoe333@hotmail.com or 400603

Custom lists

Authorized users can define custom lists. A custom list must have at least one primary key column, and zero or more value columns. A list can include optional effective dates.

Defining a custom list

To define a custom list, follow this procedure:
1
In Data Studio, create a new list.
2
Choose a category: ALERT MANAGEMENT or GENERIC.
The effective dates fields are added automatically when the Use Effective Dates checkbox is selected.

Populating a custom list

Once you have defined a custom list, you can start adding list entries. Entries can be added manually, or they can be added dynamically (when business rules are triggered).

Maintaining custom lists

Marqeta recommends that you follow these list maintenance practices:
  • Apply strict permission controls so that only users with a higher authority can access and modify the lists.
  • Use effective dates to retire an entry from a list instead of removing it, as a way to maintain full traceability.
  • Set an appropriate time to live (TTL) for each list, based on the nature of the list.
  • Keep complete audit information for each list.
Once a list has been created, you can add new non-key columns to it, but you cannot modify any existing columns. You can delete a list if it is not used by any feature.

Using a list for lookups

To use a list for lookups, you must create one or several features from the list to use when building business rules and models. Real-Time Decisioning Data Studio provides an intuitive user interface (UI) to build features from a list.

Updating lists

You can update a list manually from the Manage List page in the Real-Time Decisioning Data Studio.

Updating a list with a rule action

Follow these steps to update a list using a Data Source Update action in a rule:
1
Define a rule that contains the UPDATE DATASOURCE action.
2
Select the Insert and Update option to update only the list columns specified in the action. If a specified column is null, it will not be updated. To replace an existing record completely, use the Insert and Replace option instead. If you want to replace an existing record completely, use the Insert and Replace option.
3
Add the rule set that contains the list update rule to a Decision Flow.

Testing features and rules with list dependencies

When testing features and rules that have dependencies on one or more lists, you can select the list data you want to use when performing the test.

Testing features

When testing a feature that uses a list for lookups, you can select a list that is operating in production or use datasets that have been inserted into the list. When using the list in production, the test is performed directly against the production system and will return the most up-to-date result. When using inserted datasets, the test does not affect the production system, but the test result may match the production system result.

Calculating features

When you configure a Feature Calculate task that uses production data, if any selected feature has a dependency on a list, the system will prompt you to select one or more datasets that have been inserted into the list for the calculation task. There is no option to use the list in the production system. The event data for calculation is from the production system, but the data for the list is from datasets only. This behavior prevents the Feature Calculate task from competing for resources against real-time list lookup tasks. If a feature or any of its upstream-dependency features were previously calculated in production, the system will use the existing calculated result. You have the option to force the re-calculation of one or more features and their dependencies by enabling the Advanced option, however.

Running Quick Tests for rules, scorecards, and decision flow

When running Quick Test on a rule, scorecard, or decision flow that has dependencies on one or more lists, the system will use production data for the dependent lists for the lookup. Because Quick Test allows up to 1000 testing events, using production data in this scenario has negligible impact on the production system.

Running basic, comparison, and simulation tests for rules and scorecards

Real-Time Decisioning does not support basic, comparison, or simulation tests on a rule, nor does it support scorecards that have dependencies on one or more lists.