# Model Config sub-pages explained *Fraud Management app ยท Merchant model examples* Each model in the Fraud Management app has a set of configuration sub-pages. Below, each one is explained in two parts: what it is and why it exists, and an example of what it holds. The examples come from the Merchant model configured in the app. Figures that are not on the screens are illustrations. ## 1. Request XPaths **What it is:** The fraud application can accept a transaction from any system, and each system names its fields differently. One system sends the terminal as "TerminalId", another as "AcceptorId", another as "DeviceId". Request XPaths is the mapping. For each name the model uses, we tell it where in the incoming message to read that value, and what type it is (text, number or true/false). Rules then use one stable name, whatever the source system calls it. **Example:** - The Merchant model has 18 mappings, for example `AmountEUR` read from `//AmountEUR` as a decimal number, `MerchantId`, `CardIssuerCountry`, `EntryMode`, `MCC` and `IsRecurring`. - If a new QR system sends the payer's country as "PayerCountry", we add one mapping row. No rule changes. ## 2. TTL Counters **What it is:** These keep running counts and totals for one entity, such as a merchant, a terminal or a card, over a time window. Rules read them later. "TTL" means the counter forgets events older than its window, so it always shows only the recent period. **Example:** - The Merchant model has 370 of them. Each name reads as entity, window, metric. - `merchant 1d count_cross_border_tx`: how many cross-border transactions this merchant had in the last day. The same counter exists for 1 week and 30 days. - `merchant 30d sum_eur_crossborder_chargebacks`: the total EUR of chargebacks on those transactions over 30 days. - So they come in two kinds: counts, and totals (sums). ## 3. Gateway Rules **What it is:** The front door of the model. Before any scoring, these rules decide which transactions the model should look at, label them, and say what share to check. They run in priority order, lower number first. A gateway rule can also be a trusted fast path that skips the other checks. **Example:** - `HighValueMerchantDeposit` picks deposits above 10,000 EUR. - `StructuringAmountFilter` picks deposits from 9,000 up to just under 10,000, the amounts just below a reporting limit. - `ChargebackFilter` picks chargebacks. - `ManualPanKeyEntrySample` picks manually keyed card entries and checks only 50% of them. `TechnicalFallbackSample` checks 20%. The Sample % saves effort on low-risk volume. ## 4. Abstraction Rules **What it is:** These work out a summary value from history, such as a count, total, average, maximum, distinct count or standard deviation, over a time window for one key, such as one merchant. Later rules compare the current transaction with these values. The difference from TTL counters is that counters keep simple counts and totals, while abstraction rules compute richer statistics. **Example:** - `MerchantAvgTicketEUR30Day`: the average transaction amount of this merchant over 30 days. - `MerchantMaxTicketEUR1Day`: the biggest transaction today. - `MerchantDistinctCardIssuerCountries1Day`: how many different countries' cards paid this merchant today. ## 5. Calculations **What it is:** These combine two abstraction values with simple arithmetic (add, subtract, divide), or with a small script, to make a new measure that a single number cannot show. **Example:** - `MerchantTicketDeviationScore` = the biggest sale today minus the 30-day average. It shows how far today's biggest sale is from normal. - `MerchantVolumeRatio7vs1Day` = 7-day volume divided by 1-day volume. - `MerchantAcceptorCombinedVolumeEUR` = the merchant's 7-day volume plus the terminal's 30-day volume. ## 6. HTTP Adaptation **What it is:** It lets the model ask an outside web service for extra information while scoring, and then use the answer like any other value. Some intelligence lives outside, such as IP reputation or a risk score held in another system. You set the address, the method, a time limit, authentication, whether to remember answers, and what to do if the service fails (scoring carries on). **Example:** - The Merchant model has `MerchantRiskScoreLookup`. It calls an outside address, with a 3-second limit and no password, and receives a risk score. - In this demo the address is a test page that returns a fixed 9.0. In a real set-up it would call the client's own risk system. ## 7. Inline Functions **What it is:** Small formulas that are saved with a name and reused: joining text, a yes/no check, or arithmetic. You prepare a value once instead of repeating the logic in many rules. **Example:** - `format_merchant_display_name` (text) joins the merchant ID and country, giving "M100 (AE)". - `is_high_risk_merchant_mcc` (yes/no) is true when the merchant category is one of 7995, 5816, 6051, 6010 or 6011. These are typically gambling, digital games and cash- or crypto-type categories. ## 8. Inline Scripts **What it is:** The same idea as functions, but for logic that needs several steps, such as if-then-else with several inputs. A script takes named inputs from the transaction or the counters. It runs in a protected sandbox with a time limit, so it cannot harm the system. A function is one expression, and a script is a few steps. **Example:** - `cal_merchant_velocity_ratio` takes the count in the last 12 hours and the count in the last day, and returns the first divided by the second, times 100. - If the answer is 75, three quarters of the day's activity happened in the last 12 hours, which suggests a recent burst. ## 9. Sanctions **What it is:** It screens names in the transaction against the sanctions lists, even when the spelling differs. You choose which field to screen and how many letters may differ (the distance). 0 means exact only, and 2 is the usual fuzzy match. Results can be remembered, so the same name is not screened again and again. **Example:** - The Merchant model screens `MerchantName` and `BeneficiaryName`, each with distance 2. - "Alpha Tradng" would match "Alpha Trading" on the list. ## 10. Tags **What it is:** A tag is a named label, worked out from a condition and attached to the transaction. Rules and reports can then use the label, instead of repeating the logic. Change the condition once, and everything that uses the tag follows. **Example:** - `HighVolumeMerchant`: the merchant's 1-day volume is above 50,000. - `CrossBorderMerchant`: merchant country differs from the transaction country. - `ManualEntryMerchant`: the card was keyed in by hand. - `SanctionedCountryMerchant` and `RecurringMerchantTx`. ## 11. Synchronisation **What it is:** The model's rules and settings are kept ready in memory so scoring is fast. This page shows whether the latest configuration is loaded, so changes made on the screens take effect without a software release. **Example:** - An analyst changes a gateway rule from "above 10,000" to "above 8,000" and saves. - The Synchronisation page shows the model loaded and active, and the next transaction is judged with 8,000. ## Presenter notes (for you only) - Gateway rule 1, "Bypass - Sanctioned Card Issuer Country", is a bypass type. By the code, a bypass match is approved on the fast path, which sounds opposite to its name. Skip that row, or check the intent with the team. - The outside web address in HTTP Adaptation is a test site. Say "an outside service" and do not read the address out. - These descriptions come from the application's configuration and code. Check the labels once on the live pages before presenting.