Rules and decision outcomes

Rules Studio is where you build the decision logic that evaluates an application and routes it to an outcome — Approve, Decline, Review, or Request Docs. A rule is a branching tree: each node checks a condition against data pulled from a credit bureau, a verification service, a bank connection, or your own tenant/application data, and each branch either assigns an outcome or hands the application to another decision tree.

---

How a rule is structured

A rule (shown in Rules Studio as a “workflow”) is built as a tree of nodes in a visual editor. Each node represents a condition or an action, and it branches into a left and a right child — typically the “true” and “false” paths of the condition above it.

At any node you can:

• Pick a variable to evaluate (see Variable sources below) and set an operator and a comparison value.
• Assign an outcome action to that branch: Approve, Decline, Review, or Request Docs.
• Chain the branch into another, already-built decision tree instead of (or in addition to) assigning an action directly.
• Attach a task template to the node, with an assignee and a due-date rule, so reaching that branch automatically creates a follow-up task.

Conditions and operators

The operators available on a condition depend on the type of the variable you’re testing:

• Number variables: is equal to, is not equal to, greater than, greater than or equal to, less than, less than or equal to, is null, is not null.
• String variables: is equal to, is not equal to, contains, does not contain, begins with, ends with, is null, is not null.
• Boolean variables: is equal to, is not equal to.
• Date variables: is equal to, is not equal to, is after, is after or equal to, is before, is before or equal to, is null, is not null.
• List variables (single-select): the same set as string conditions.
• List variables (multi-select): contains all, does not contain all, contained by, not contained by, shares at least one element, does not share at least one element, shares exactly one element, does not share exactly one element. List values are entered as comma-separated values or in bracket notation, for example 1, 2 or "ca", "tx" or [1, 2].

Variable sources

Conditions can reference variables from a wide range of sources, including:

• Credit bureau pulls (TransUnion Soft and Hard, Experian, Equifax, Clarity, FactorTrust, and others).
• Identity and fraud verification services (Socure, Prove, SentiLink, InstantID, IPQualityScore, and others).
• Bank account and income data providers (Plaid, Flinks, Sophtron, Ocrolus, Prism Data, and others).
• Decisioning and scoring platforms (Zest AI, Oscilar, BaseLayer, Trust Science, and others).
• System input, form input, tenant-level data, and derived output produced earlier in the same rule.

The full list of connected providers is long and tenant-dependent; the variable picker in the node editor only shows the providers enabled for your tenant.

---

Decision outcomes (actions)

Every branch of a rule ends by assigning one of four outcome actions:

Action	Notes
Approve
Decline
Review
Request Docs	Shown as “Req doc” in some list views

These four actions are the fixed set a rule can assign at a node. A separate Decision Outcomes area in the sidebar is where these outcomes are referenced elsewhere in the platform (for example, on the application underwriting view), but this page does not have enough source detail to describe adding outcome types beyond these four — see Unclear.

---

Versions and the approval workflow

Rules are versioned. Each version has a status, a creator, and — once acted on — an approver or decliner, a timestamp, and an optional note. Only one version at a time is marked as the default version.

1. Create a rule. In Rules Studio, create a new rule with a name and description.
2. Edit the tree. Open the rule and build or change the condition/action nodes, then save.
3. Copy to a draft. Use “copy to draft” to duplicate an existing version into a new draft you can keep editing without disturbing the version that’s currently in use.
4. Submit for approval. Submit a version for approval with a description. You can choose whether approving it should also make it the default version.
5. Approve or decline. An approver can approve the version, or decline it with a reason.
6. Set the default version. You can also set any existing version as the default directly, without going through approval, using “set default version.”
7. Toggle the rule active or inactive. A rule can be turned on or off as a whole, separate from its version history.

The version marked default is the one referenced when the rule is applied. Editing a version that is currently the default changes what’s actively in effect for the rule, so most teams clone to a draft first.

Testing a rule before publishing

Rules Studio includes a test run option on a rule version: you supply sample input data and the system returns the path taken through the tree and the resulting action, letting you confirm the logic before submitting the version for approval.

Scoping to tenants, products, and pricing

A rule version can be scoped to specific sub-tenants, and associated with a specific assigned product and pricing engine, so the same rule library can carry different versions for different products or business lines.

---

Worked example

A lender wants a rule for its “Personal Loan – Standard Tier” product that uses a TransUnion Soft credit pull and a debt-to-income (DTI) figure to sort applications into three outcomes.

1. An operator opens Rules Studio and creates a new rule named “Personal Loan – Standard Tier Decisioning.”
2. In the node editor, they add a first condition node: variable = TransUnion Soft credit score, operator = “is greater than or equal to,” value = 660.
   • True branch: a second condition node checks DTI, operator = “is less than or equal to,” value = 40. If true, the node is assigned the Approve action.
   • False branch of the DTI check: assigned Review, with a task template attached, assignee set to the underwriting queue, and a due date rule.
3. On the False branch of the original score check (score below 660), they add another condition: score “is greater than or equal to” 620.
   • True: assigned Review.
   • False (score below 620): assigned Decline.
4. The operator runs a test with sample applicant data (score 645, DTI 35%) using the test run option, and confirms the path lands on Review as expected.
5. They save the version as a draft, then submit it for approval with a description, checking the box to make it the default version once approved.
6. Once approved, the version becomes the default, and new applications for this product are evaluated against this tree.

---

Use case

A credit union wants to auto-decline applications below a 580 FICO score without a manual review step. Its rules team builds a single condition node checking the credit score variable with operator “is less than,” value 580, and assigns the Decline action directly to that branch — with no task template attached, so no manual review task is created. Applications scoring 580 or above fall through to the rest of the tree, which routes them to Review or Approve depending on further conditions.

---

Best practices

• Test a version with the test run option before submitting it for approval. Confirm the path and resulting action match what you expect for realistic sample data.
• Clone the current default version to a draft before making changes, rather than editing the live default directly, so an in-progress edit doesn’t affect applications being decisioned right now.
• Use the description field when submitting a version for approval, and the reason field when declining one, so the version history explains why a change was made or rejected.
• Only mark a version as default when you intend it to take effect immediately — set-default takes effect without going through the approval step.
• Attach a task template to a Review branch (with an assignee and due date) when the outcome needs a person to act on it, rather than leaving the application to sit with no follow-up.

---

Unclear

• Whether the Decision Outcomes sidebar area supports creating outcome types beyond the four built-in actions (Approve, Decline, Review, Request Docs), or only displays/reports on them.
• What happens if a version is declined after it was already set as the default, or whether declining removes default status.
• What “Request Docs” triggers beyond labeling a branch — whether it automatically sends a document request to the applicant or only marks the outcome for staff to act on.
• What the “chain” value returned by a test run represents beyond linking to another decision tree.
• Whether approval and decline actions are restricted by user role, and if so, which roles.
• Whether toggling a rule inactive affects applications already in progress under that rule, or only new applications.