Rules
<<glossary:PayRule>> is <<glossary:Banking.Live>>'s rules and decision engine. <<glossary:PayRule>> advances the authorization process of consumer behaviour by utilising a proprietary wide-data array designed to enable high-speed card transaction history retrieval & analysis at the point of spend.
<<glossary:PayRule>> can stream the complete analytics (rules and actions) set to you mid-flight during the authorization message through the <<glossary:FAST>> interface rules node.
<<glossary:PayRule>> supports authorization, clearing, scheduled events and specific API calls. These features enable cash-rewards, fraud prevention and spend limit control. Thus, enabling you to provide cardholders with the ultimate seamless spending journey.
Clients can opt in to
<<glossary:PayRule>>or use their own rules engine.
Transaction classification
Paymentology offers extensive capabilities when it comes to categorizing and identifying transactions as required by issuers globally. At a high level, <<glossary:PayRule>> caters to the following categories:
| Category | Description | |
|---|---|---|
| Spend type | Transaction type e.g. POS transaction | Current and/or historic |
| Spend mode and validation | Chip, eCommerce, contactless etc. | Current and/or historic |
| Include approvals, declines, reversals | DE39 responses, and message types | Current and/or historic |
| Location constraints | Terminal, Merchant ID, retailer, postcode, city, country etc. | Current and/or historic |
| Advanced settings | ||
| POS terminal attendance | Attended, unattended etc. | Current and/or historic |
| Terminal location | On/off premises | Current and/or historic |
| Cardholder presence | Cardholder presence | Current and/or historic |
| Card presence | CP (card present)/CNP (card not present) etc. | Current and/or historic |
| Card capture capability | If the card can be captured or not. | Current and/or historic |
| Transaction Status | Pre-auth, ATM inquiry, SecureCode etc. | Current and/or historic |
| Cardholder activated terminal level | Level 1-9 | Current and/or historic |
| Terminal capability | What the terminal being used is capable of | Current and/or historic |
This is a limited selection of the key metrics that can be compiled for analytics that matter to your business.
Action optionality
While all analytics of the rules engine are real-time, we do not enforce a decision-making process based on a rule being triggered and flagged over the <<glossary:FAST>> interface.
As a standard practice, we support one or multiple actions that add security and optionality on how to integrate the receiving ledger with real-time analytics data.
Key actions:
- Send alerts: AML/card fraud team, cardholder, customer service, or custom recipients, either via SMS or email.
- Decline transaction: Paymentology puts extra safety nets in place to ensure compliant processing of non-compliant transactions.
- Dynamic blocks: temporarily block tokens (cards) while investigating transaction patterns occurring due to suspicious transaction behaviours.
- Merchant blocks: deny access to merchants creating abnormal transactional behaviour at the Merchant ID level.
Trigger metrics
Analyzing transaction classifiers has no benefits without competent metrics to ensure validity for business requirements. At a high level, Paymentology will compile rules based on your requirements in the following metric categories:
| Metric | Description |
|---|---|
| Time window | Rolling time window or calendar-based analysis of transaction metrics as they occur |
| Spend count | Number of transactions to trigger rule |
| Cumulative spend amount | Cumulative total value |
| Reset time window | Ability to dynamically reset the time window based on specific events |
| Include estimation | To get/send the remaining amount and/or count in FAST |
| Spend amount | Transaction amount |
| Spend currency | Transaction currency |
| MCC | Merchant Category Code |
| Additional data | Additional data provided in the transaction message |
| Test results | Test results of the transaction and card tests performed intra-spend |
Configuration
As <<glossary:Banking.Live>> is <<glossary:API>>-driven, rules and actions can also be created and amended through the use of APIs. This means that rules can be updated immediately in real-time via <<glossary:API>> or the rules wizard in <<glossary:PayControl>>.
ImportantDepending on the client's setup, Paymentology manages the creation and amendment of rules during production. Therefore, some clients might not have access to the full
<<glossary:PayRule>><<glossary:API>>suite.
Fees and limits
As <<glossary:PayRule>> also manages specific fee and limit types. You can read more about these through the links below:
Updated 7 months ago