Signal Rules

With Signal Rules, you can configure your decision logic directly within the Signal Dashboard using templates from Plaid, then use Dashboard tools to tailor the rules to your own traffic.

Signal Rules can be based on scores (higher scores indicate higher risk), attributes of the transaction, or a combination.

You can set up the following actions for your business to take as a result of a rule:

• ACCEPT and process the transaction

• REVIEW the transaction further before processing

• REROUTE the customer to another payment method, as the transaction is too risky

You can also create more complex action flows through the use of custom action keys

You can define a single ruleset for all your transactions, or you can build use-case specific rulesets, such as one for an initial deposit during customer onboarding and another for a returning customer depositing funds.

Create rulesets on the Signal Rules Dashboard page. You can create a ruleset from scratch, or Plaid can suggest an initial rule template relevant for your use case.

Rules are evaluated sequentially, from top to bottom, typically ordered by the severity of the rule violation. If data that the rule depends on is not available, the rule will be skipped.

The result of the first rule that matches will be applied to the transaction and included in the /signal/evaluate response. You will be required to have a fallback rule that is applied if no other rules match.

To evaluate a transaction's risk, call /signal/evaluate and include the required request properties in addition to the ruleset's ruleset_key, which can be found in the Dashboard, in smaller type under the name of the ruleset.

The more properties you provide when calling /signal/evaluate, such as the user or device fields, the more accurate the results will be. Providing the client_user_id is also recommended to aid in your debugging process later.

In the response, use the ruleset.result property to determine the next steps.

Most integrations use the result to decide between approving a payment for processing (result=APPROVE), or rerouting the consumer to another payment method (result=REROUTE). If that's the case with your integration, ensure that your ruleset emits only these two result types.

If your integration is taking more complex actions before deciding whether to process the transaction (for example, sending certain transactions to a manual review queue), use the REVIEW result type. Remember to report the final decision for these reviewed transactions later.

Customers who used Signal Rules before May 2025 used the ruleset.outcome field. This field has been replaced by ruleset.result. Update your integration to use the new values from the ruleset.result field:

For most integrations, that's all you need to change. Once you've updated your integration, inform your account manager.

If you have an advanced use case where you take different actions for transactions with the same result, you can use the custom_action_key. For example, to apply a variable hold time, make sure your Signal rules emit an result=ACCEPT value for all transactions you intend to process. Then, use the custom_action_key to define a 3-day-hold for some rules and 5-day-hold for others. For more details, see Using a custom action key.

Some integrations may need more options for handling a transaction than the three choices of accept, review, or reroute. For example, you might want to apply a variable hold time to transactions that were accepted and processed, depending on the level of risk. Or you may want to apply labeling to their transactions to denote a cohort for data analysis purposes. To support more complex actions, check the "Configure advanced options" box on the rule editing screen and specify a custom_action_key.

You can then create multiple rules with the same result but different custom actions. For example:

• If medium risk, ACCEPT with custom_action_key=5-day-hold

• If low risk, ACCEPT with custom_action_key=3-day-hold

When calling /signal/evaluate, use the custom_action_key in the response to determine the action to take.

The amount of consumer-permissioned data available to Signal can vary. Most Signal evaluations will return information about the Item's use in the network, the latest balance, historical balance information, or account activity. The full set of data is usually available to Signal within 15 seconds of Plaid Link being completed. However, if /signal/evaluate is called before this process completes, or the Item has been inactive for a long time, partial data may be returned.

When used with Items that do not have a connection to a financial institution, (i.e., Items created verified using alternative methods such as micro-deposits or Database Auth), Signal can collect a subeset of data for approximately 30% of these Items. If Signal can't get data, the scores property will be null, and any rules using score will be skipped (potentially triggering your fallback rule). You will still be billed for the evaluation (unless you have no Signal Ruleset enabled).

In the Sandbox environment, scores and attributes returned by /signal/evaluate will be randomly generated. You can influence the score returned by /signal/evaluate in Sandbox by providing particular values in the amount request field. Use the values from the following table to control the returned score:

You can use these hardcoded responses and create simple rules in Sandbox (such as REROUTE if bank_score == 90) to test various result types.

All evaluations can be viewed in realtime on the transactions viewer Dashboard page. Look up your transaction using its client_transaction_id. You can see its scores, the ruleset's result, and the data used to build the score.

You can view all transactions that matched a specific rule by clicking View Performance in the ... icon on the rule.

After your integration is live and you are reporting returns, Signal will report metrics such as approval rate, return rate, and top ACH return codes.

Once you have at least several hundred transactions completed, you can view your traffic's risk score distribution on the performance page in the Dashboard.

Drag the slider to see estimated approval rate versus return rate tradeoffs. Using this data, you can update your existing rules, and backtest the potential changes.

Signal can provide extremely accurate backtested results when lowering your accepted maximum risk score (e.g. going from using 70 to 60 as the cutoff for accepted transactions). However, when raising your risk tolerance, Signal will provide an estimated range for the return rate. This is because you would now process transactions that were previously not approved, so concrete data on the results of those transactions is inherently not available. As a result, when increasing your risk threshold, you should move slowly and incrementally.

Plaid strongly recommends using Signal Rules. However, if you have your own risk management system in which you are using Signal as one of multiple data sources, you might choose to ingest Signal data directly via the API instead instead. If you don't use Signal Rules, Plaid may be limited in the support it can offer you in tuning external logic.

To directly access Signal's scores and data attributes, call /signal/evaluate. The scores and core_attributes properties in the response will contain the raw Signal data you can provide to your model. For a full listing of core_attributes, see the sample response or contact your Account Manager.

Even if you aren't using Signal Rules, it's still recommended to report decisions and returns in order to use the Signal Performance pane, which helps you find the right score threshold.