> ## Documentation Index
> Fetch the complete documentation index at: https://www.marqeta.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Real-Time Decisioning Dashboard Quick Start

> Learn how to use the Real-Time Decisioning dashboard to configure decisioning controls.

Marqeta's Real-Time Decisioning dashboard lets you build and manage the controls that approve, decline, or flag card transactions as they happen.

By the end of this guide, you will understand how to:

* Configure how Real-Time Decisioning processes transaction events and where to find response data and reports
* Access the dashboard and set up user roles
* Create, test, and publish features that store and aggregate transaction data
* Build data lists to use in your rules
* Create, test, and publish rules that approve, decline, or flag transactions
* Review past events to investigate transaction activity

<h2 id="_about_real_time_decisioning">
  About Real-Time Decisioning
</h2>

Real-Time Decisioning enables you to apply finely tuned controls to card transactions.
You can personalize your card program while managing risk and fraud.

Marqeta provides a Real-Time Decisioning dashboard to create controls on transaction authorizations for decisioning and monitoring.
Supporting the dashboard is the Real-Time Decisioning risk engine, which executes these controls in the authorization flow, deciding in real time whether or not to approve, decline, or generate an alert on the transaction.
If one or more controls are triggered, the response is passed through in the JSON payload.

For more information, see the [RiskControl Overview](/developer-guides/real-time-decisioning-landing-page/) landing page.

<h3 id="_scope">
  Scope
</h3>

Real-Time Decisioning currently supports all card transactions in the authorization flow.
You can create controls to make a decision on account-to-account transfers (original credit transactions, or OCTs), account funding transactions (AFTs), ATM withdrawals, authorizations, cashback authorizations, incremental authorizations, quasi-cash transactions, and more.

You can also create controls to monitor other transaction types such as declines, reversals, refunds, and other transactions that are outside of the authorization flow.
Even though these transactions cannot be acted upon in real time, controls or features can be created to generate alerts or build cardholder profiles.

<Note>
  Real-Time Decisioning does not process settlement or clearing transactions for decisioning or monitoring.
</Note>

For more information, see the [RiskControl Transaction Event Types](/developer-guides/riskcontrol-transaction-event-types/) page.

<h3 id="_transaction_event_processing">
  Transaction event processing
</h3>

Real-Time Decisioning processes every supported transaction as an event. There are three supported event types:

* `TRANSACTION_RT`: This event type corresponds to all real-time transactions in the authorization flow.
  Any control that requires decisioning is created using this event type.

* `TRANSACTION`: This event type corresponds to all processed authorization transactions, as well as transactions coming from outside the authorization flow.
  Because these transactions have already been processed, they cannot be acted upon in real time.
  Any feature that requires the transaction's final status is created using this event type.

* `CARD_FRAUD`: This event type corresponds to API events coming from the [Fraud Feedback API](/core-api/fraud-feedback/).
  This event type is used to build controls for the rule suppression use case.

To apply Real-Time Decisioning to transactions during the authorization flow, create controls on the `TRANSACTION_RT` event type.
Features can be created on the `TRANSACTION` event type for aggregation- or profile-building purposes.

<h3 id="_response_payload">
  Response payload
</h3>

Real-Time Decisioning appends the response in the transaction payload, which is available in JIT Funding requests and in webhooks.
The Real-Time Decisioning response object includes information on the risk score, risk level, and recommended action, as well as information on the rules that were triggered while authorizing the transaction.
Custom tags defined in the rule logic are also returned in the response if the corresponding rule is triggered.

For detailed information about Real-Time Decisioning response payloads, see [RiskControl objects](/developer-guides/riskcontrol-objects/).

<h3 id="_access_reports">
  Access reports
</h3>

Real-Time Decisioning publishes two reports in the Marqeta Dashboard.
These reports are available in the **Reports** section of the **RiskControl Real-Time Decisioning** dropdown list:

* **RiskControl Real-Time Decisioning Authorizations:** Returns information on all the transaction authorizations processed by Real-Time Decisioning.
  It includes the following fields: `acting_user_token`, `amount`, `card_token`, `recommended_action`, `risk_level`, `risk_score`, `rule_violation`, `tags`, `transaction_token`, and `user_token`.

* **RiskControl Real-Time Decisioning Transaction Count By Rules:** Returns the number of transactions per triggered rule for the program.

<h2 id="_real_time_decisioning_dashboard">
  Real-Time Decisioning dashboard
</h2>

Use the Real-Time Decisioning dashboard to configure Real-Time Decisioning controls.

Access to the Real-Time Decisioning dashboard is provisioned separately from Marqeta Dashboard access.
Separate Real-Time Decisioning credentials are required.

<h3 id="_access_the_dashboard">
  Access the dashboard
</h3>

You can access the Real-Time Decisioning dashboard from the Marqeta Dashboard under the **RiskControl > Real-Time Decisioning** dashboard section.

Currently, single sign-on from the Marqeta Dashboard to the Real-Time Decisioning dashboard is not available.

Your Real-Time Decisioning dashboard administrative user can provide access to other users in your program.

<h3 id="_feature_overview">
  Feature overview
</h3>

The Real-Time Decisioning dashboard provides a user interface where you can define rules and features.
It also enables you to investigate past transaction data.
The dashboard has the following features:

* **Insights Center:** Use the Insights Center to search and query past transaction data.

* **Data Studio:** Use the Data Studio to import an external data set or to create a data list that you can use to build features.

* **Feature Platform:** Use the Feature Platform to create, manage, and test features.
  Use the features you create to build rules in the Rules Engine.

* **Rules Engine:** Use the Rules Engine to create, manage, and test rules.

* **System Monitoring:** System Monitoring provides visibility into audit logs and the Task Center associated with the dashboard.

* **Admin:** Manage user accounts and dashboard configurations.

<h3 id="_user_roles">
  User roles
</h3>

There are three user roles in the Real-Time Decisioning dashboard:

* **Tenant Administrator:** The Tenant Administrator role has superuser access, including the ability to set up other user accounts and access to all dashboard features.

* **Tenant Analyst:** The Tenant Analyst role can create, manage, test, and publish rules and features.
  A Tenant Analyst can also query data to investigate past transaction events.

* **Tenant Guest:** The Tenant Guest role has view-only access to rules and features.
  Guests cannot create or update existing rules or features.

<Note>
  Use the Tenant Administrator role only for users who require superuser privileges.
  Otherwise, use the Tenant Analyst role to allow users to manage and create rules and features.
</Note>

<h3 id="_create_features">
  Create features
</h3>

Create **Features** on the **Feature Platform > Create Feature** tab to store values or fields in a collection that you can then use when creating your rules.
For example, if you want to create a rule to decline transactions when the cardholder has already conducted more than 10 transactions in last day, define a feature to store the transaction count for the last day and then use this feature in the rule.

To create a feature:

<Steps>
  <Step>
    Provide a feature name, an optional description, and an optional tag.
  </Step>

  <Step>
    Select the **Operator**.
  </Step>

  <Step>
    Select the **Target** on which the Operator will operate.
  </Step>

  <Step>
    Select the **Aggregate By** entity.
  </Step>

  <Step>
    Define the time period for the data aggregation.
  </Step>

  <Step>
    Select the **Event Type** for which the feature should be evaluated.
  </Step>
</Steps>

For example, if you want to store the count of transactions for every cardholder for last 24 hours, select `count` as the Operator, `transaction_amount` as the Target, Aggregated By `transaction_acting_user_token`, `24 hours` as the Time Period, and `TRANSACTION_RT` as the Event Type.

You can add optional conditions to your features using **Add Criteria**.
For example, in the case above, if you only want to store the count of card present transactions, click **Add Criteria** and select the `transaction_pos_card_presence = true` attribute.

<h3 id="_publish_features">
  Publish features
</h3>

You can publish features on the **Feature Platform > View Features** tab.
This tab displays information about all of your features.
Use the filter or search functionality to find individual features.

You can find the status of a feature in the **Status** column.
A feature can be in one of two states:

* **DRAFT:** Features are created in the draft status by default.
  To update or modify any feature, move it into the draft status.

* **PUBLISHED:** Published features are executed on all transactions.
  You can also prepopulate features using historical data so they are ready to be used as soon as they are published.

<h3 id="_create_and_store_data_lists">
  Create and store data lists
</h3>

Data lists are used to store data elements that can then be used in your rules.
For example, you can create a data list of high-risk merchants.

You can create a data list on the **Data Studio > Manage List** tab.

To create a data list:

<Steps>
  <Step>
    Click **Create list**.
  </Step>

  <Step>
    Provide the list name and category.
  </Step>

  <Step>
    Click **Add Field** to add the field name and select the field type.
  </Step>
</Steps>

Once you have created a list, you can then add records to it.
In order to use the list in a rule, first create a feature on the list:

* Under **Create new feature**, select an item from the data list. After the feature is created, you can use the list in a rule.

<h3 id="_create_rules">
  Create rules
</h3>

Create a rule to define a control that you want to execute on transaction events.

Create new rules on the **Rules Engine > Create Rules** tab.

* To create a rule, define a rule name, provide an optional description, add an optional tag, add conditions, and specify an action.

* To add conditions, select features from the **Feature** dropdown list.
  The dropdown list shows all the fields present in the transaction payload, as well as any user-defined features.
  You can create multiple blocks of conditions.

You can select two types of actions for rules: primary and secondary.

* There are three primary actions:

  * **APPROVE:** Use this action to suppress triggered rules and allow transactions.

  * **REJECT:** Use this action to decline transactions.

  * **REVIEW:** Use this action to generate an alert.

* Select the secondary action **Tag** to add a custom tag in the **Action Data** field.

<h3 id="_test_rules">
  Test rules
</h3>

You can test rules using the **Quick Test** feature.
Quick Test allows you to test your rule against historical production data.

You can select individual event identifiers or historical data.
When working with historical data, you can select up to 1000 of the latest transaction records or select a specific period of time.

You can then select the event types.
For example, to test your rules on authorization transactions, select **Event Type - TRANSACTION\_RT**.

Quick Test returns information about individual historical transactions, including the rule outcome, in the result table.

You can also use the **Statistic view** tab to visualize Quick Test results and rule parameters holistically.

<h3 id="_publish_rules">
  Publish rules
</h3>

You can publish rules on the **Rule Engine > View Rules** tab.
This tab displays information about all of your Real-Time Decisioning rules.
Use the filter or search functionality to find individual rules.

You can find the status of the rule in the **Status** column.
A rule can be in any of the following three states:

* **DRAFT:** Rules are created in the draft status by default. To update or modify any rule, move it into the draft status.

* **TRIAL:** Rules in the trial status execute on all transactions, but do not result in any decision on the transaction when they are triggered.
  This behavior lets you validate the impact of rules before publishing them.

* **PUBLISHED:** Published rules are executed on all transactions and result in a decision on the transaction when they are triggered.

<h3 id="_view_past_events">
  View past events
</h3>

Every event processed by Real-Time Decisioning can be accessed in the Real-Time Decisioning dashboard, either by searching directly in the search bar or by using the Insight Center.
You can use the search bar if you know the `user_id` or `event_id` of the event you want to retrieve.

In the Insight Center, you can search for an event on the Global Search tab.
You can also use the **Explore** feature to write a query to pull past transaction data.


## Related topics

- [RiskControl Overview](/docs/developer-guides/real-time-decisioning-landing-page.md)
- [Dashboard Overview and Quick Start](/docs/developer-guides/dashboard-overview-and-quick-start.md)
- [Core API Quick Start](/docs/developer-guides/core-api-quick-start.md)
- [2022 Release Notes](/docs/developer-guides/release-notes-2022.md)
- [Real-Time Decisioning Authorizations](/docs/diva-api/real-time-decisioning-authorizations.md)