Context

Introduction

The Rules subdomain provides the necessary features to establish and enforce guidelines across all financial transactions on the platform. It plays a critical role in ensuring transactions adhere to legal regulations, company policies, and compliance frameworks.

The subdomain supports two type of Rules for the following use cases:

• Usage Restriction Rules: Applies rules on all transactions made with any Card linked to a specific Account. The primary goal is to restrict the conditions under which transactions can occur, ensuring they comply with predefined criteria.

• Expense Limit Rules: Applies spending limits to individual Cards to enforce budget constraints and prevent overspending.

Rules are made of one or several Rule Criteria to match against a transaction. Rules use AND logic: all criteria must be met for a rule to apply. In this case, the transaction is rejected.

An Account can have multiple Usage Restriction Rules. A Card can have multiple Expense Limit Rules. This creates a multi-level relationships between Accounts, Cards, and Rules.

A Rule can have multiple Rule Criteria, creating a 1-n relationship between Rules and Rule Criteria.

graph LR;
    Account[Account] -->|1..n| Card[Card]
    Account[Account] -->|1..m| UsageRestrictionRule[Usage Restriction Rule]
    Card[Card] -->|1..p| ExpenseLimitRule[Expense Limit Rule]
    UsageRestrictionRule[Usage Restriction Rule] -->|1..q| RuleCriterion[Rule Criterion]
    ExpenseLimitRule[Expense Limit Rule] -->|1..r| RuleCriterion[Rule Criterion]

Hold "Alt" / "Option" to enable pan & zoom

Relation to Adyen's Concepts

The Rules subdomain relies on Adyen Transaction Rules API, but provides a higher level model that is more business-oriented than the versatile but complex Adyen data model.

• Usage Restriction Rules correspond to Adyen Transaction Rules of type blockList that are applied to the Adyen Balance Account matching the rule's Account.

• Expense Limit Rules correspond to Adyen Transaction Rules of type velocity that are applied to the Adyen Payment Instrument matching the rule's Card.

In addition to Transaction Rules, Adyen also supports an Authorization Relay model where Adyen sends an authoeization webhook on each ongoing transaction. The Payment Gateway does not implement this model yet, but our data model is designed to be compatible with both methods and also with other PSPs that would provide similar features.

Our entities use the external_id field as a unique identifier, storing the corresponding Adyen ID for each entity within our system, thus ensuring a seamless mapping process between the two data models.

Source of Truth and Lifecycle Management

Usage Restriction Rules

Info

The class UsageRestrictionsLogic is responsible for Usage Restriction Rules lifecycle management.

Usage Restriction Rules lifecycles are fully managed within the component, encompassing creation, modification, and termination. Each Usage Restriction Rule on our platform is directly mirrored by a corresponding Adyen Transaction Rule.

Our component is the primary source of truth and takes full ownership of their lifecycle management, with each Usage Restriction Rule on our side having a corresponding Adyen Transaction Rule. This setup ensures a one-way synchronization from our component to Adyen, reflecting our component's proactive role in managing these financial entities. Changes in Adyen need manual replication in our system; however, given our component's control over the full Usage Restriction Rule liefecycle, such situations are exceptional.

Expense Limit Rules

Info

The class ExpenseLimitsLogic is responsible for Expense Limit Rules lifecycle management.

Expense Limit Rules lifecycles are fully managed within the component, encompassing creation, modification, and termination. Each Expense Limit Rule on our platform is directly mirrored by a corresponding Adyen Transaction Rule.

Our component is the primary source of truth and takes full ownership of their lifecycle management, with each Expense Limit Rule on our side having a corresponding Adyen Transaction Rule. This setup ensures a one-way synchronization from our component to Adyen, reflecting our component's proactive role in managing these financial entities. Changes in Adyen need manual replication in our system; however, given our component's control over the full Expense Limit Rule liefecycle, such situations are exceptional.