# Nornhill: Payment Systems & Modern Infrastructure (Complete Technical Knowledge Base) > Canonical Website: https://nornhill.com > Manifest: https://nornhill.com/llms.txt > Target Audience: AI agents, LLM search engines, fintech engineers, payment architects, product managers. This document provides a token-efficient, plain-text markdown representation of Nornhill's complete educational knowledge base. It details the underlying mathematical formulas, architectural loops, risk models, regulatory compliance constraints (PSD2/SCA, EU IFR, US Durbin Amendment, PCI DSS 6.4.3), and full technical articles published by Nornhill. ## Table of Contents 1. Core Payment Simulators & Architectural Specifications - 1.1 Payment Pricing Calculator: Blended vs Interchange Plus Plus (IC++) - 1.2 Payment Routing & Cascading Engine - 1.3 Multi-Way Reconciliation & Settlement Break Engine - 1.4 Real-Time Payment Fraud Detection & 3DS Step-Up Engine - 1.5 Payment Gateway Architecture & Tokenization Blueprint 2. Real-World Architecture Case Studies - 2.1 Smart Routing for 18M Monthly Transactions Gateway - 2.2 90% Fraud Reduction for Non-3DS Checkout Flow - 2.3 +300bps Authorisation Lift via Mastercard Token Service - 2.4 PSD2/SCA-Compliant Analytics at Checkout (PCI DSS 6.4.3) 3. Technical Research Papers - 3.1 ISO 20022 Migration Guide & Message Mapping - 3.2 Analytics & Observability for Payment Gateways 4. Full Technical Articles & Research Insights --- ## 1. Core Payment Simulators & Architectural Specifications ### 1.1 Payment Pricing Calculator: Blended vs Interchange Plus Plus (IC++) - **Canonical URL**: https://nornhill.com/tools/pricing-calculation - **Purpose**: Compare total processing costs, fee transparency, and merchant margins between Blended Flat Rate and IC++ pass-through pricing models across different transaction mixes. #### Mathematical Models: 1. **Blended Flat Fee**: ``` Total Blended Cost = (Transaction Volume * Blended Percentage) + (Transaction Count * Fixed Fee) ``` 2. **Interchange Plus Plus (IC++) Model**: ``` Total IC++ Cost = Interchange Wholesale Fee + Scheme Assessment Fee + Acquirer Markup + (Transaction Count * Fixed Acquirer Fee) ``` 3. **Net Margin Differential**: ``` Merchant Cost Savings = Total Blended Cost - Total IC++ Cost ``` #### Key Fee Drivers: - **Interchange (Wholesale)**: Paid to the card-issuing bank. Regulated in the EU/UK under Interchange Fee Regulation (IFR 2015/751) at 0.20% for consumer debit and 0.30% for consumer credit. Regulated in the US under the Durbin Amendment at 0.05% + $0.21 for covered banks (> $10B assets). Unregulated commercial, corporate, and international rewards cards range from 1.50% to 2.80%+. - **Scheme Assessments**: Non-negotiable network fees charged by Visa and Mastercard (clearing, licensing, brand assessment). Range between 0.08% and 0.15% plus fixed authorization fees for domestic transactions; international fees apply when cardholder and merchant countries diverge. - **Acquirer Markup**: Negotiable processor margin representing payment routing, risk underwriting, and service fees. - **Interchange Downgrades**: Occur when transactions fail to settle within 24-48 hours, lack Address Verification (AVS), or omit CVV confirmation, escalating interchange from prime tiers to Standard/EIRB rates (+50 to 100bps). --- ### 1.2 Payment Routing & Cascading Engine - **Canonical URL**: https://nornhill.com/tools/routing-simulator - **Purpose**: Optimize multi-acquirer transaction delivery, minimize processing costs, and maximize authorization rates through dynamic cascading and retry logic. #### Core Routing Mechanisms: 1. **Pre-Routing Evaluation**: Inspects incoming Card BIN, issuing country, currency, transaction size, and merchant category code (MCC) prior to acquirer dispatch. 2. **Dynamic Load Balancing**: Distributes transaction volume across multiple acquiring partners based on volume tiers, contractual commitments, and historical acceptance rates. 3. **Decline Code Taxonomy**: - **Soft Declines (Retryable)**: Code 51 (Insufficient Funds), Code 91 (System Error / Acquirer Timeout), Code 96 (System Malfunction), Code 19 (Re-enter Transaction). Soft declines trigger smart retries or silent secondary PSP cascading. - **Hard Declines (Terminal)**: Code 04 (Pick Up Card), Code 14 (Invalid Account Number), Code 41 (Lost Card), Code 43 (Stolen Card), Code 54 (Expired Card), Code 57 (Transaction Not Permitted). Hard declines abort immediately to prevent card testing penalties and scheme fines. 4. **Silent Cascading**: When primary acquirer response exceeds timeout thresholds (e.g., 3,000ms) or yields a retryable soft decline, the transaction is automatically re-authorized through an alternative PSP without merchant checkout interruption. --- ### 1.3 Multi-Way Reconciliation & Settlement Break Engine - **Canonical URL**: https://nornhill.com/tools/reconciliation-simulator - **Purpose**: Simulate multi-stage ledger reconciliation between merchant internal order systems, gateway authorization logs, and bank settlement files to detect financial breaks. #### Three-Way Matching Methodology: 1. **Stage 1 (Internal vs Gateway)**: Match Order Management System (OMS) orders with Payment Gateway authorization/capture logs using `merchant_order_id`, currency, and amount. 2. **Stage 2 (Gateway vs Acquirer Settlement)**: Match captured gateway authorizations with Acquirer Electronic Payment Advice (EPA), CAMT.053, or 822 settlement files using `scheme_transaction_id`, `authorization_code`, and net settled funds. 3. **Break Classification & Detection**: - **Timing Breaks**: Batches captured near midnight cutoffs settling on subsequent business days (T+1 / T+2). - **Currency / FX Breaks**: Discrepancies between authorized exchange rate and batch settlement FX execution. - **Fee Variance Breaks**: Unannounced scheme assessments or interchange downgrade fees deducted at settlement. 4. **Automated Journal Adjustments**: System writes automated balancing entries to suspense accounts and alerts finance teams when variance exceeds pre-set thresholds. --- ### 1.4 Real-Time Payment Fraud Detection & 3DS Step-Up Engine - **Canonical URL**: https://nornhill.com/tools/fraud-detection-simulator - **Purpose**: Execute sub-50ms pre-authorization transaction risk scoring, behavioral velocity tracking, and dynamic 3-D Secure 2.2 step-up logic. #### Risk Engine Architecture: 1. **Sub-50ms Scoring**: Composite scoring (0-100) analyzing IP geolocation, proxy/VPN detection, device fingerprint entropy, email domain risk, and transaction history. 2. **Behavioral Velocity Rules**: Tracks card velocity per IP, IP velocity per card, failed attempt sequences, and rapid micro-authorization card testing attacks. 3. **Dynamic 3-D Secure 2.2 Orchestration**: - **Frictionless Exemption (Score < 30)**: Requests SCA exemption under PSD2 (Transaction Risk Analysis - TRA for low-fraud portfolios up to 500 EUR, or Low-Value Exemption under 30 EUR up to 100 EUR cumulative). - **Dynamic Challenge (Score 31-80)**: Invokes 3DS biometric/SMS challenge for elevated risk transactions, shifting chargeback fraud liability to the card issuer. - **Hard Block (Score > 80)**: Aborts authorization before hitting scheme networks to prevent chargebacks and scheme compliance ratio breaches. --- ### 1.5 Payment Gateway Architecture & Tokenization Blueprint - **Canonical URL**: https://nornhill.com/tools/gateway-architecture - **Purpose**: Interactive blueprint illustrating PCI DSS zero-trust vault boundaries, network tokenization, idempotent API design, and asynchronous webhook dispatching. #### System Architecture Layers: 1. **API Gateway & Rate Limiting**: Ingests merchant API traffic, enforces rate limits, validates HMAC signatures, and deduplicates requests using the `Idempotency-Key` header. 2. **Card Tokenization Vault**: Isolated, PCI DSS Level 1 compliant environment. Hosted fields or SDKs send card data directly to the vault. Raw PAN and CVV never touch merchant application servers. 3. **Network Tokenization (VTS / MDES)**: Integrates Visa Token Service and Mastercard Digital Enablement Service. Replaces PANs with network tokens that automatically update upon card reissuance and generate dynamic transaction cryptograms lifting approval rates by 200-400bps. 4. **Asynchronous Webhook Pipeline**: Queue-backed webhook dispatchers with exponential backoff retries and cryptographic payload signatures to guarantee at-least-once notification delivery. --- ## 2. Real-World Architecture Case Studies - **Canonical URL**: https://nornhill.com/cases ### 2.1 Smart Routing for 18M Monthly Transactions Gateway - **Domain**: Payment Orchestration / High-Risk Payment Platform - **Key Metrics**: +15pp acceptance rate gain, 130+ PSP integrations, 40+ countries. - **Architectural Solution**: A high-volume payment gateway processing 18M monthly transactions through a single PSP configuration suffered severe drop-offs during regional latency spikes. The architecture was rebuilt from the ground up: - *Discovery*: Audited existing PSP connections, failure modes, and error codes across 40+ countries. - *Architecture*: Implemented a provider abstraction layer decoupling business rules from PSP protocols. - *Routing Engine*: Deployed BIN, currency, and latency-weighted routing with real-time silent failover on soft declines. - *Scale*: Onboarded 130+ integrations via a standardized interface, reducing integration overhead by ~60%. ### 2.2 90% Fraud Reduction for Non-3DS Checkout Flow - **Domain**: Fraud Prevention / Video Streaming Platform - **Key Metrics**: 90% fraud reduction, <50ms risk scoring latency, 0% conversion impact. - **Architectural Solution**: 65% of volume was generated through Smart TV apps where 3DS iframes cannot render. Removing 3DS invited card-testing attacks at scale: - *Engine Design*: Built a behavioral ML risk engine on Elasticsearch tracking device entropy, session timing, and event sequences. - *Shadow Mode*: Calibrated risk score thresholds in parallel against live traffic with zero merchant impact. - *Scheme Negotiation*: Presented behavioral data to Visa and Mastercard as evidence of sufficient merchant controls, establishing compliant non-3DS processing and cutting fraud by 90% in 60 days. ### 2.3 +300bps Authorisation Lift via Mastercard Token Service - **Domain**: Network Tokenisation / Subscription Merchant - **Key Metrics**: +300bps authorization rate lift, ~90% overall approval rate, zero token assets lost during migration. - **Architectural Solution**: Card-on-file recurring payments suffered elevated decline rates from expired cards and stored-credential fragmentation: - *Vault Decoupling*: Separated token storage from any single PSP, enabling multi-acquirer portability. - *MDES Integration*: Deployed Mastercard Token Service (MDES) with automated lifecycle provisioning and token refresh. - *Provider Portability*: Leveraged network tokens to migrate payment providers seamlessly without customer re-entry. ### 2.4 PSD2/SCA-Compliant Launch of Tracking Tools at Checkout - **Domain**: Regulatory Compliance / High-Risk Operator - **Key Metrics**: 100% PCI compliance, <100ms load time latency, zero data leaks. - **Architectural Solution**: Integrating qualitative analytics into payment checkout flows while complying with PCI DSS Requirement 6.4.3: - *Scope Isolation*: Restricted analytics strictly to pages without direct cardholder PAN/CVV entry. - *Script Verification*: Implemented Subresource Integrity (SRI) hash validation and rigorous Content Security Policy (CSP) whitelisting to prevent supply-chain tampering. --- ## 3. Technical Research Papers - **Canonical URL**: https://nornhill.com/papers ### 3.1 ISO 20022 Migration Guide & Message Mapping - **Canonical URL**: https://nornhill.com/papers/iso20022 - **Core Topics**: Transitioning legacy SWIFT MT103/MT940 financial messages to rich ISO 20022 XML formats (pacs.008 customer credit transfers, pacs.002 payment status reports, and camt.053 end-of-day bank statements). Architectural strategies for data truncation prevention, UTF-8 structured addressing, and real-time payment rail alignment (SEPA, FedNow, CHAPS). ### 3.2 Analytics & Observability for Payment Gateways - **Canonical URL**: https://nornhill.com/papers/analytics-for-payment-gateway - **Core Topics**: Building high-scale telemetry pipelines for payment gateways. Defining error taxonomies (issuer decline vs network timeout vs gateway validation error), monitoring authorization approval ratios by issuing BIN in real time, and configuring automated alert thresholds for acquirer degradation. --- ## 4. Full Technical Articles & Research Insights ### Blended vs IC++ Pricing Explained - **Canonical URL**: https://nornhill.com/insights/blended-vs-interchange-pricing - **Author**: Ivan Voitenko - **Category**: Operations - **Summary**: Blended flat rate vs Interchange explained for product managers. What interchange, scheme fees and acquirer markup really cost, what drives them, and how to negotiate IC++ with a practical checklist. Card payments look simple at checkout, but each one has a complicated cost structure set by Visa, Mastercard, and the issuing bank. How you buy this bundle from your acquirer can impact your profit margin. We built the Blended vs IC++ Pricing simulator on [nornhill.com](/tools/pricing-calculation) because product and payments teams often ask themselves whether they are paying too much under a flat rate or whether switching to pass-through pricing could save money after improving their card mix. This article explains the different types of fees, how they work, what influences them, and where you can actually negotiate. ## The three cost layers A card payment includes three separate fees, not just one as your processor may have said. **Interchange** is the wholesale fee paid to the cardholder’s issuing bank. It is usually the largest part of the total card cost, accounting for about 70-90%. Card networks set the rates, and issuers get the money. While you cannot negotiate interchange directly, you can influence which interchange category applies to your transactions. **Scheme Assessment** covers network infrastructure, clearing, and brand fees charged by Visa or Mastercard. It is the first + in IC++. These are usually shown as a percentage plus a fixed fee, for example, about 0.08% for Visa in Europe, plus a small amount per transaction. But it could also be a 1.028%, as it depends on the product and region. **Acquirer Markup** is the margin your payment processor keeps for services like authorisation, settlement, risk management, reporting, and support. It is the second + in IC++. This is the only fee layer you can really negotiate. Transaction Flow & Cost Attribution Layers ## Blended vs Interchange Plus Plus A Blended Flat Rate combines all three fee layers into a single fixed price, such as 2.9% + $0.30. It is a well-known fee formula widely used by [Stripe](https://stripe.com/pricing). This makes costs easy to predict and explain within your company. The processor takes on the risk of price changes and keeps any extra margin from low-cost transactions. Interchange Plus Plus (IC++) passes through interchange and scheme fees at their actual cost, then adds two clear markups: one for the scheme and one for the acquirer. This way, you can see exactly how much goes to the network, the issuer, and your processor. **When is IC++ a better choice? **Flat blended rates are based on the highest-cost scenarios, like cross-border or corporate cards. If most of your transactions are consumer debit or domestic credit, you lose a lot of margin with blended pricing. Switching to IC++ lets you see the real wholesale costs and save money right away. **When is blended pricing better?** If you process a lot of international, premium rewards, commercial cards, or card-not-present transactions without 3DS, a flat rate might be cheaper because the provider covers the high interchange costs. [As Mollie points out](https://www.mollie.com/gb/growth/payment-processing-fees-guide), IC++ helps you benefit from low domestic rates, but blended pricing can be more cost-effective for businesses with many international or premium payments. Transaction Fee Structure: Blended vs IC++ ($100 Debit Sale)Proportional Cost Scale ComparisonBlended Model ($3.20)$0.23$2.97IC++ Model ($0.38)$0.38-88% fee savingInterchange (IC)Scheme Fee (+)Acquirer Markup (+)Processor Margin (Spread)Blended Model$3.20Flat rate billing (e.g. 2.9% + $0.30). Processor absorbs underlying costs and retains the residual spread.Wholesale Costs (Interchange & Scheme)$0.23Processor Retained Spread$2.97Pass-ThroughIC++ Model$0.38Wholesale costs passed through at exact cost, with a transparent contract markup added.Interchange (IC)$0.20Scheme Assessment (+)$0.03Acquirer Markup (+)$0.15Total Savings on This Transaction88% fee reduction on domestic consumer debit routing.Saved: +$2.82 per transaction ## What drives interchange Interchange is not one number. Card networks publish hundreds of categories. The rate you get depends on: ### Card product - Debit vs credit. Debit is cheaper. In the EEA and UK, consumer debit is capped at 0.20% and consumer credit at 0.30% by regulation. - Premium rewards vs basic. Premium cards carry higher interchange to fund rewards. - Consumer vs commercial. Commercial, corporate and purchasing cards are unregulated and can be 1.50% to 2.50%+. Worldpay shows Visa Commercial Credit at 1.40% to 2.00% and Mastercard Commercial Credit at 1.65% to 2.25%. ### Region and routing - Domestic vs intra-regional vs inter-regional. EEA domestic consumer cards are capped. The cross-border UK-EEA card not present rate can be 1.15% for debit and 1.50% for credit. - Local acquiring matters. Adyen explains that costs are much lower when transactions are processed through a local acquirer within the same region. Cross-border transactions are typically subject to significantly higher interchange rates. ### Transaction environment - Card present vs card not present. CP with chip and PIN is lower risk than CNP. Stripe notes that online payments are more expensive because they carry higher fraud and chargeback risk. - 3D Secure and network tokenisation. Implementing 3DS and DPAN tokens can move you into lower interchange categories and avoid clear-text PAN downgrades. ### Merchant Category Code - MCC defines your risk profile and eligibility for specialised rates. Supermarkets, utilities, education and government can access lower caps. [Worldpay notes](https://assets.ctfassets.net/zhwqbd2ar3b8/5kqsxR0QLBkjkNjtxcwmzU/d6862dbf2e8ea59cf864516f97bb3f03/Worldpay_UK_Simple_IC__SF_Rate_Card_April_2024.pdf) that Visa Everyday Spend MCCs 4111, 5411, 5541, etc., can qualify for reduced scheme fees. ### Data quality and settlement hygiene - AVS, CVV, Level 2/3 data. For B2B, supplying the tax amount, invoice number, and line-item details can reduce commercial card interchange. - Settlement timing. [JPMorgan’s guide stresses](https://www.jpmorgan.com/content/dam/jpm/merchant-services/documents/jpmorgan-interchange-guide.pdf) settling within 24 hours for retail and within 2 days of the ship date for e-commerce to avoid downgrades. Interchange Rate Card Benchmarks (UK/EEA April 2024)Card Type & CategoryRegion & EnvironmentInterchange RateRegulatory StatusConsumer DebitUK & EEA Domestic, CNP / CP0.20%Capped (EEA)Consumer CreditUK & EEA Domestic, CNP / CP0.30%Capped (EEA)Cross-Border Consumer DebitEEA to UK (Card Not Present)1.15%UncappedCross-Border Consumer CreditEEA to UK (Card Not Present)1.50%UncappedCommercial / Business CreditDomestic / Regional Credit1.40% – 2.25%High Margin LeakageInter-Regional Consumer (US Card)US to UK/EEA (Card Not Present)1.60% – 2.50%+UncappedNote: Rates represent simple averages from Worldpay UK rate cards and Visa/Mastercard schedules. Commercial and inter-regional cards are primary drivers of profit margins for flat blended billing engines. **Scheme fees you cannot ignore** Scheme fees are one of the +. They are smaller than interchange, but they compound, especially on refunds and authentication events. Visa and Mastercard publish country-level interchange PDFs. [Mastercard’s UK hub explains](https://www.mastercard.com/gb/en/business/support/merchant-interchange-rates.html) that interchange is set to balance acceptance and issuance incentives. [Visa Europe lists](https://www.visa.co.uk/about-visa/visa-in-europe/fees-and-interchange.html) inter- and intra-EEA categories separately. Refunds also attract scheme fees. [Worldpay notes](https://assets.ctfassets.net/zhwqbd2ar3b8/5kqsxR0QLBkjkNjtxcwmzU/d6862dbf2e8ea59cf864516f97bb3f03/Worldpay_UK_Simple_IC__SF_Rate_Card_April_2024.pdf) Mastercard refunds are charged as per a sale transaction, and Visa refunds outside EEA can be 0% interchange returned. ## How blended pricing hides margin A blended rate like 2.9% + $0.30 seems predictable. But if 60% of your transactions are UK domestic debit, capped at 0.20% plus about 0.03% for scheme fees, the processor keeps an extra 2.6% on those payments. This extra margin helps cover their losses on high-cost transactions, like US corporate rewards cards with 2.6% interchange. IC++ makes this cross-subsidy clear. For example, you pay 0.20% + 0.03% + an acquirer markup, say 0.07%, on debit cards, and 2.6% + scheme fees plus 0.07% on corporate cards. If most of your transactions are debit, your average cost can be much lower than 2.9%. [Nuvei explains it well](https://www.nuvei.com/posts/strategic-considerations-for-minimizing-international-payment-gateway-fees-in-cross-border-commerce): IC++ separates the interchange paid to the issuing bank, the scheme fee paid to the network, and the acquirer markup. This transparency is why many enterprises prefer IC++ for detailed cost control. ## Negotiation levers that actually work You cannot negotiate the interchange rates themselves, but you can negotiate everything else related to your payments. ### Acquirer markup This is the second plus in IC++. Compare it on a basis points plus a fixed fee per transaction basis. For high-volume merchants in Europe, rates of 5 to 15 basis points + $0.05 are possible. Ask your provider about volume tiers and commitment thresholds. ### Scheme fee pass-through Insist on true pass-through with no padding. Some PSPs blend scheme fees into markup. Ask for monthly scheme fee invoices broken by Visa FANF, Mastercard Acquirer Program Support, etc. ### Card mix optimisation - Increase debit share via local payment methods, e.g. iDEAL, Bancontact, Pix. [Nuvei notes](https://www.nuvei.com/posts/strategic-considerations-for-minimizing-international-payment-gateway-fees-in-cross-border-commerce) that alternative payment methods often have lower processing costs than international card networks. - Send domestic transactions through local acquirers. Using local acquiring removes cross-border surcharges, which can be as high as 2%, and also helps improve approval rates. ### Authentication and data quality - Enable 3DS2 and network tokens. [Adyen says](https://www.adyen.com/en_GB/knowledge-hub/interchange-fees-explained) security tools like AVS can trigger lower interchange categories. - Send Level 2/3 data for B2B. JPMorgan recommends including verification support, AVS and cardholder verification data to improve interchange qualification. ### MCC and settlement hygiene - Check your MCC assignment. Having the wrong MCC can put you in a higher risk category. - Settle transactions every day. According to [JPMorgan’s best practices](https://www.jpmorgan.com/content/dam/jpm/merchant-services/documents/jpmorgan-interchange-guide.pdf), settling late often leads to downgrades. ### Refund and dispute discipline High chargeback ratios trigger risk premium markups. [Solidgate advises](https://solidgate.com/blog/interchange-fees-explained/#optimizing-interchange-fees) using AVS to reduce fraud and chargebacks, which can lead to increased interchange. ### Contract terms - Request IC++ pricing with interchange and scheme fees at cost, and a fixed acquirer markup for 24 months. - Cap cross-border fees or get separate pricing for domestic vs inter-regional. - Negotiate to remove minimum monthly fees if you agree to volume commitments. Optimization Framework #### Merchant Negotiation Leverage Profile Estimated Leverage Impact: 190 – 315 bps01Local AcquiringRouting OptimizationRoute regional cards through local entities to eliminate cross-border card fees.Impact150 – 200 bps02B2B Level 2/3 DataCommercial Invoice PayloadsSend detailed purchase parameters for commercial transactions to lower wholesale rates.Impact15 – 50 bps03Acquirer Markup MarginPSP Markup NegotiationsInsist on pass-through IC++ and benchmark the markup to basis points matching monthly volumes.Impact10 – 30 bps043DS2 & Network TokensSecure Card CredentialsShift chargeback liability and qualify for lower interchange tiers using secure auth flags.Impact10 – 20 bps05Settlement Lag HygieneClearing Schedule AlignmentSettle card authorizations within 24 to 48 hours to avoid interchange downgrade penalties.Impact5 – 15 bps ## How to decide which model fits you We use a simple decision framework in our simulator. **Input your business profile:** - Monthly processing volume and transaction count to derive AOV - Card mix: domestic debit %, domestic credit %, international %, commercial % - Current blended rate and fixed fee **Set negotiation levers:** - Card present ratio - Network token and 3DS adoption - MCC profile - Settlement window - Dispute and refund rates The model matches your card mix to Visa and Mastercard wholesale interchange tables, adds scheme fees from [Worldpay’s rate card](https://assets.ctfassets.net/zhwqbd2ar3b8/5kqsxR0QLBkjkNjtxcwmzU/d6862dbf2e8ea59cf864516f97bb3f03/Worldpay_UK_Simple_IC__SF_Rate_Card_April_2024.pdf), and includes the acquirer markup. It then compares your annual blended cost to the IC++ cost. Yes, Worldpay's rates are not the best, but they are real and sufficient for the simulation to avoid misleading you or being overly optimistic. So even after that, you know that you can negotiate those fees. ## Practical checklist for product managers - Pull a 3-month sample of authorisations with card product, region, CP/CNP flag, 3DS result, MCC and settlement lag. - Classify each transaction into Visa and Mastercard interchange buckets using the EEA tables. - Calculate weighted average interchange + scheme. - Add target acquirer markup, e.g. 0.10%. - Compare to the current blended effective rate. If weighted wholesale + markup is >50 bps below the blended rate, start an IC++ RFP. ### Regulatory context to watch - EEA/UK caps: 0.20% debit, 0.30% credit for consumer cards. Business cards are uncapped. - UK-EEA cross-border: post Brexit, cross-border fees jumped to 1.15% debit and 1.50% credit for CNP. The UK PSR is pushing for a new cap. - US: no federal cap, premium rewards drive interchange above 2%. [Stripe’s guide reminds](https://stripe.com/resources/more/interchange-fees-101-what-they-are-how-they-work-and-how-to-cut-costs#how-are-interchange-fees-calculated) that interchange is typically a percentage plus a fixed fee, and networks update tables twice a year. Plan a biannual pricing review. ## Final thought Blended pricing gives you simplicity. IC++ gives you more control. For product teams, control is important when you can influence factors like routing to local acquirers, using network tokens, improving 3DS adoption, updating MCCs, and settling on time. These actions help you qualify for lower interchange rates, and with IC++ you keep those savings. We developed the Blended vs IC++ Pricing simulator to help you see this trade-off clearly. Use it to model your current card mix, try out negotiation scenarios, and decide whether greater transparency into payment costs is warranted. [](/tools/pricing-calculation)Interactive Simulator ### Blended vs IC++ Pricing Model regional interchange caps, card network assessment fees, and cross-border routing overhead to expose flat-rate processing leakage. Launch Tool ### How Revolut and NU Bank Use AI for Financial Profiles - **Canonical URL**: https://nornhill.com/insights/pragma-nuformer-financial-fingerprints - **Author**: Ivan Voitenko - **Category**: AI - **Summary**: How Revolut’s PRAGMA and Nubank’s nuFormer turn raw banking events into financial fingerprints. We break down encoder vs decoder designs, auditability risks, and what product teams should take away for credit, fraud and personalisation. We visited Revolut's headquarters in Canary Wharf. The office was impressive, and from the balcony, you could see the JPMorgan Chase tower, which seemed fitting. Anton Repushko introduced PRAGMA, Revolut’s core banking model. In short, PRAGMA creates a unique financial fingerprint for each user. It was trained on 1.5 years of raw data, including transactions, app activity, trading, and support chats. That’s over 40 billion events from 25 million users in more than 100 countries. All this data is turned into a dense vector, which is a few hundred numbers used as embeddings. After the event, our LinkedIn post received a lot of attention. Most comments focused on two main topics: auditability and real-world impact. This article expands on that discussion and is based on two papers we read afterwards: PRAGMA Foundation Mode from Revolut: [https://arxiv.org/pdf/2604.08649](https://arxiv.org/pdf/2604.08649) Modeling Financial Habits with Transformers from Nubank: [https://arxiv.org/pdf/2507.23267](https://arxiv.org/pdf/2507.23267) Revolut is our main focus since we saw it in action, but Nubank shows that the industry is moving forward with a different approach. ## **What PRAGMA actually is?** The model doesn’t create a summary you can read. Instead, it stores each user’s behaviours and patterns. For example, it might notice if someone pays rent on the 1st, tops up on weekends, buys ETH often, or travels to Spain every two months. All this information is stored as a vector of numbers, not as text. This is an important point for anyone familiar with AI to remember. That’s what encoder-only means. Typical large language models are decoders—they predict the next word and generate text. We’ll return to this difference as things get more complex. The architecture is built for different types of banking data. Each event is a set of key-value pairs with a timestamp. PRAGMA uses a key-value-time tokenisation method. Keys are single tokens. Values are encoded by type: numbers are grouped by percentile with an extra group for zero, categories map to one token, and text is split into subwords using BPE (Byte Pair Encoding, a data compression and subword tokenisation method). Time is encoded both as log seconds since the last event and as calendar features. Tokenisation overview. A raw event record is decomposed into keys and values. Keys are always represented by one token. Time is encoded, and time features are derived from the timestamp. The backbone has two branches. One encodes profile state, such as plan, region, and balance quantile, as well as lifelong events, such as the first top-up. The other encodes events. Outputs are fused by a history encoder. The model is pre-trained with masked modelling. During pre-training, random tokens from a user’s event history are hidden, and the model learns to reconstruct them. By repeating this across billions of events, the model learns the underlying patterns of financial behaviour. Event timeline overview. PRAGMA aggregate the event history up until a designated evaluation point. ## **Why encoder-only and not generative?** PRAGMA is an encoder-only model and works in both directions. Its goal is to create representations that can be used for different tasks, not to generate open-ended text. Masked modelling allows each token to use both past and future context, which helps the model fill in missing parts of event records and learn from complete histories. How is it possible? During pre-training, random tokens from a user’s event history are hidden (masked), and the model learns to reconstruct them. By repeating this across billions of events, the model learns the underlying patterns of financial behaviour. The pre-training dataset is huge. Revolut’s data science team used 26 million user records from 111 countries, 24 billion events, and 207 billion tokens, covering 25 months from 2023 to 2025. The team balances recent data with historical changes and uses sequence packing and dynamic batching to train efficiently on long, irregular histories. After pre-training, PRAGMA can be adapted in two ways. In the embedding probe setup, the main model stays the same and a small head is trained on top of the embeddings. In the LoRA fine-tuning setup, Low Rank Adaptation updates only a small part of the model’s parameters. This allows quick specialisation while keeping most of the model shared across tasks. ## **From fingerprint to products** PRAGMA acts as the foundation for many tasks. [Revolut](https://www.revolut.com/?utm_source=nornhill&utm_medium=organic&utm_campaign=ai-article) adds a small model on top of the same fingerprint. These simple models use embeddings for tasks such as fraud detection, credit scoring, lifetime value prediction, product recommendations, communication engagement, and identifying recurring transactions. According to the Revolut paper, one architecture outperformed task-specific models, achieving 130% gains in credit and 67% in fraud in their synthetic tests. However, the slide included a disclaimer: these improvements are on synthetic data, not real production results. The team also shared an interesting point about scaling. Bigger models don’t always give better results. For PRAGMA-M, 512 dimensions at 100 million parameters are enough, while 1024 dimensions for PRAGMA-L at 1 billion parameters don’t perform much better. Other speakers agreed: smaller models often do just as well on specific tasks and are much faster. Single architecture from 10M to 1B parameters that outperforms task-specific models across tasks. ## **The two questions that matter for regulated payments** As payments product managers, we asked Anton two questions that matter most for regulated payments. ### **First, about auditability** Suppose the FCA asks, "Why was this customer declined? Why was that payment not blocked? Why was the credit limit cut?” So, how do you explain a decision based on a digital fingerprint made up of 500-dimensional vectors? Anton explained that PRAGMA is currently used internally to help with decision-making. It does not conflict with current regulations, but the team knows this is still early. As mentioned earlier, there are other models for each service that provide explanations. The next step is to work with regulators to set standards and rules for foundation models in finance. There is no public timeline yet for formal talks with regulators. We expect internal model risk governance to come first, followed by discussions with regulators. Frameworks like the [EU AI Act](https://artificialintelligenceact.eu/), [UK SS1/23](https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss), and [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework) are emerging, but there is still no banking-specific standard for logging, versioning, and explaining embeddings. From an engineering standpoint, auditability for foundation models will likely require three layers: 1. Provenance logging for the backbone version and pre-training data snapshot 2. Embedding stability tests under concept drift 3. Post hoc explainers trained on top of frozen embeddings, plus counterfactual probes that show which event types moved the score ### **Second, what does this mean for users?** PRAGMA works best as a backbone. It gives a consistent user fingerprint that other models can use for different tasks. This helps reduce duplication across systems. From what we see, PRAGMA mainly serves as an internal backbone. It is built for banking operations, credit, fraud, and risk, not as a feature that users interact with directly. For users, Revolut built AIR, its AI tool. Right now, it’s just a basic chat. We expect that in a year, it will use PRAGMA embeddings. The real product challenge is not just understanding user behaviour, but connecting patterns to outcomes. For example, not just seeing that someone receives income monthly, but knowing that taxes will be paid on it, a certain amount stays each month, and giving advice on how to keep it. Some companies build the data layer mainly for their own needs, not to improve the user experience, and are satisfied with lower processing costs. The real value comes when the fingerprint is used to give real advice, not just for scoring. ## **How Nubank approaches the same problem** [Nubank’s nuFormer](https://building.nubank.com/how-nubank-uses-transformers-to-model-financial-habits-at-scale/?utm_source=nornhill&utm_medium=organic&utm_campaign=ai-article) paper offers a good comparison. The team says financial institutions hold vast amounts of user data, but using it remains difficult due to the complexity and scale involved. Most production models still turn unstructured data into hand-made tabular features. nuFormer suggests using transformer-based representation learning for transaction data, handling both text and structured details. The paper adapts the 'text is all you need' approach to transactions by representing key-value pairs as strings and training on next-token prediction. The model is causal, like GPT, and is chosen to capture long-term patterns and seasonal changes in spending. This is the decoder model that we referred to previously. The process of converting a transaction into a stringified and then tokenised form. The paper also introduces an end-to-end fine-tuning method that combines user embeddings with existing tabular features. Experiments show better results for large-scale recommendation problems at [Nubank](https://nubank.com/?utm_source=nornhill&utm_medium=organic&utm_campaign=ai-article), achieved solely through improved representation learning, not by adding new data sources. PRAGMA uses multiple data sources and is encoder-only with a clear profile state. In contrast, nuFormer uses a text-focused decoder for recommendations. Both show that foundation models can beat task-specific baselines and reduce the need for hand-crafted features. ## **What product teams should take away?** 1. The data layer is changing. We’re moving from hand-crafted features to learned fingerprints. This changes how we think about feature stores and model reuse. One backbone that encodes 24 billion events can replace many task-specific pipelines. 2. Governance is the main challenge. The technology is impressive, but in fintech, the real test is governance. To move to an AI-ready stack, you need to modernise legacy data rather than build on workarounds. Version your embeddings just like you version your models. 3. Auditability needs to be planned. If you want to use embeddings for credit or fraud, build explainability and logging into the system from the start. Regulators will expect it. Think about embedding probes with monotonic constraints for regulated outputs. 4. Bigger isn’t always better. Quality and speed matter more than parameter count, especially for real-time authorisation and fraud. PRAGMA-M with 100 million parameters and 512 dimensions is already a good fit for many tasks. ## **A final thought** Revolut is still making a name for itself as a disruptor. They are using their scale to challenge established players. The technology is impressive, but the industry advances through standards, not just new models. PRAGMA and nuFormer offer two solid approaches to the same goal: a single financial fingerprint that can be reused across products. The next 12 to 18 months will be about proving that these fingerprints are stable as things change, can be audited by regulators, and are useful for users (not just for cutting internal costs). We’ll keep following the team. We now understand what they’re doing and why. Next, we want to see how they handle auditability and production metrics. ### Pragmatism and Regulated AI at London Tech Week 2026 - **Canonical URL**: https://nornhill.com/insights/AI-in-finance-LTW26 - **Author**: Ivan Voitenko - **Category**: AI - **Summary**: Dive into the production-level realities of regulated AI from London Tech Week 2026. Explore the "human black box double standard" and fraud frameworks. This article covers the only [Finance track](https://londontechweek.com/2026-agenda?&filters.STREAM=finance-yjs5&searchgroup=8764A071-agenda) on the Transformation stage at London Tech Week 2026. Here, I focus on how AI and blockchain are being used in real-world situations. Returning to London Tech Week for my second year, I noticed the atmosphere had changed. In 2025, the event was full of bold predictions about AI’s impact on fintech, along with ongoing discussions about blockchain, stablecoins, and a ton of similar buzzwords about what the future holds. As a payments product manager, I focus on the boundaries of what is possible, transaction flows, risk systems, and what the near future holds for this industry. Comparing the official event summaries to what engineers deal with daily, there’s a clear gap between big-picture AI stories and what actually works. In this first part, I’ll explore the real limits of autonomous agents, how regulated AI operates in practice, and the changes happening in enterprise fraud prevention. These are my personal opinions and takeaways from the speakers on stage. You can also review the official short summaries from [voxo.ai](http://voxo.ai) to see what was discussed. **{{CARD: download official AI notes PDF here, giving readers access to the raw baseline text before reading your synthesis.}}** ## 1. The Fiction of 100% Control of Regulated AI One big topic on the Transformation Stage was how the UK is handling AI regulation. The official event summaries praised the UK’s principle- and outcome-based approach, saying it gives the country an edge over the stricter [EU AI Act](https://artificialintelligenceact.eu/). In theory, this model allows fintechs and banks to work with regulators to establish compliance rules together. But for risk officers who have to approve new systems, the reality is very different. At the “Driving Innovation in Regulated Industries” panel, speakers explained that having only broad principles and no clear rules can actually freeze decision-making. Yes, a lot of obvious talk about what everyone already understands. Indeed, without specific guidelines, compliance teams tend to play it safe to avoid getting in trouble with regulators (I personally saw it with stablecoins for years). That’s why many top banks keep their main transaction systems in proof-of-concept mode, waiting for clearer rules. ### The Human “Black Box” Double Standard This situation shows a clear double standard about auditability and explainability. Regulators want detailed, step-by-step logs from AI systems. But as the speakers noted, human decision-making in companies has always been a kind of “black box”. For example, when an experienced underwriter approves a risky file based on intuition or pattern recognition, there’s no way to log that in a database. Good point, but AI can do it, as it is a machine, and we can demand of it things that humans cannot do automatically. In practice, the financial industry accepts that a senior risk officer’s 'audit trail' is simply a long career without being fired. ### The Enterprise Platform Paradox To address this gap, enterprise software vendors promoted the idea of consolidating everything on a single platform. For example, ServiceNow’s 2026 purchase of Traceloop was presented as a way to power its “AI Control Tower”. Vendors claim that having a single codebase and data model solves all the challenges of managing AI agents. They say they can completely control, log, and govern agent behaviour (“We have the tools to do that 100%”). From an infrastructure point of view, this is an oversimplification that mainly appeals to risk-averse executives. Forcing complex, high-speed transaction logic or real-time payments into a generic workflow system adds delays and makes systems fragile. This extra layer hides problems instead of fixing them. Big banks and public sector organisations don’t buy these all-in-one platforms because they are not the best for deploying AI agents. They buy them to shift risk and liability to a large vendor, trading real engineering quality for a compliance stamp. It relates to product people, as one of a PM's goals is to reduce liabilities and shift as much as possible to providers. So it was a great reminder of business mindset at the top level. ***{{CARD: "Driving Innovation in Regulated Industries and Ensuring Compliance in the Age of AI". LINK: ***[***https://media.nornhill.com/public/pdf/LTW26%20-%20AI-Driven%20Fraud%20Prevention%20in%20Action.pdf***](https://media.nornhill.com/public/pdf/LTW26%20-%20AI-Driven%20Fraud%20Prevention%20in%20Action.pdf)***}}*** ## 2. The Allica Bank Framework of AI Usage While abstract AI strategies struggle, practical financial institutions are moving pilots into production by strictly separating duties based on credit risk and decision complexity. On the panel “*How Agentic AI is Transforming Financial Services*,” Richard Davies (CEO of Allica Bank) and Conrad Ford (Chief Product & Strategy Officer) explained that moving beyond abstract, top-down strategies means having a clear separation of responsibilities: `┌────────────────────────────────────────────────────────┐`│ UNSTRUCTURED DATA INGESTION │ │ (PDF Financial Statements, Invoices, KYC) │ └───────────────────────────┬────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────┐ │ AUTOMATED EXECUTION LAYER │ │ - AI-driven unstructured-to-deterministic parsing │ │ - Zero Algorithmic Risk / Low Data Friction │ └───────────────────────────┬────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────┐ │ HUMAN CONVICTION GATEWAY │ │ - Technology as strictly an Enablement Layer │ │ - Routing data to human underwriters in real-time │ │ - Final Sign-off on High-Exposure Files │ └────────────────────────────────────────────────────────┘ **The Automated Execution Layer**. AI works best at the edges of data ingestion. In real production, the focus is on normalising unstructured data—turning messy financial statements and PDF files into clear database formats. This gives a big operational boost without adding algorithmic risk to the main transaction engine. **The Human Conviction Gateway**. For high-risk corporate files, complex loans, and tough decisions, autonomous agents reach their limit. In these cases, technology just helps by getting the right data to human underwriters at the right moment, rather than trying to automate the final call. ***{{CARD: "How Agentic AI is Transforming Financial Services and The Path to a Fully Autonomous AI-Bank". LINK: ***[***https://media.nornhill.com/public/pdf/LTW26%20-%20The%20Path%20to%20a%20Fully%20Autonomous%20AI-Bank.pdf***](https://media.nornhill.com/public/pdf/LTW26%20-%20The%20Path%20to%20a%20Fully%20Autonomous%20AI-Bank.pdf)***}}*** ### ## 3. AI-Driven Fraud Prevention at Starling Bank The main takeaway from the session “*AI-Driven Fraud Prevention in Action” *was clear: fraud rates are hitting record highs because criminals are using advanced AI to run more sophisticated scams. Adding AI as a core defence is now essential to keep up with these fast, precise threats. Instead of treating AI as a one-size-fits-all fix, the focus has shifted to targeted integration that adds “intelligent friction” right where it’s needed in the customer journey. Bernadette Smith, Chief Compliance Officer and MLRO at Starling Bank, shared real results from two main AI-driven projects that show this approach works: **Call Status Indicator**. This high-value vishing (voice phishing) prevention. A real-time network analysis tool identifies whether a customer is on an active call with a non-bank entity while simultaneously attempting a high-value transfer. The immediate, actionable alert has driven a staggering **73% decrease** in bank impersonation scams. UK neo-banks introducing customer-facing features to stay safe with evolving fraud [**SCAM Intelligence**](https://www.starlingbank.com/news/scam-intelligence-launch/)**.** This is high-volume purchase fraud, and the tool empowers users to analyse marketplace advertisements or listings for fraud indicators before sending money. By tailoring the intervention to the context of the transaction, it has led to a **300% increase** in customers voluntarily abandoning high-risk transactions, proving far more effective than traditional, static payment warnings. ### The Fight for Ecosystem Accountability The session ended with a strong critique of the current liability model, which puts too much operational pressure on financial institutions. This setup hurts competition and hits smaller fintechs the hardest. Starling’s Bernadette Smith called for a shift to shared liability, especially for unregulated tech platforms like Meta, where most consumer scams start. To really fight fraud, the whole ecosystem (including banks, fintechs, and social networks) needs to work together and be motivated to stop financial crime at its source. Bernadette Smith, Chief Customer and Banking Officer at Starling Bank, talking about AI usage in fraud prevention ***{{CARD: "AI-Driven Fraud Prevention in Action". LINK: ***[***https://media.nornhill.com/public/pdf/LTW26%20-%20AI-Driven%20Fraud%20Prevention%20in%20Action.pdf***](https://media.nornhill.com/public/pdf/LTW26%20-%20AI-Driven%20Fraud%20Prevention%20in%20Action.pdf)***}}*** ## 4. AI in Compliance In the final tracking session, *Ensuring Compliance in the Age of AI*, compliance specialists explained that core compliance systems are quickly moving away from keyword and string-matching and toward anomaly detection. These older methods just don’t work for today’s risk challenges. Large Language Models (LLMs) are changing how we monitor communications across channels like email, MS Teams, and Bloomberg messenger, as well as voice transcriptions for high-risk people. Instead of just sending raw, isolated alerts, GenAI engines now build full case stories and give analysts automated recommendations. ### Engineering the Hybrid Pipeline However, speakers noted that massive production scaling is heavily bottlenecked by API costs, token efficiency, and execution latency. To optimize these performance funnels under production constraints, tier-1 institutions are deploying hybrid pipelines: `[Raw Transaction/Communication Stream]` │ ▼ ┌────────────────────────────────────────────────────────┐ │ CLASSIC DATA SCIENCE STACK │ │ (Initial Filtering & Anomaly Triage at Scale) │ └───────────────────────────┬────────────────────────────┘ │ (High-Risk Anomaly Filtered) ▼ ┌────────────────────────────────────────────────────────┐ │ TARGETED LLM ENGINES │ │ (Contextual Narrative & Rich Disposition) │ └───────────────────────────┬────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────┐ │ HUMAN ANALYST VALIDATION │ │ (Critical Thinking & Final Sign-Off) │ └────────────────────────────────────────────────────────┘ This hybrid approach makes sure that computing power and costly LLM tokens are used only for complex cases, keeping standard transaction processing fast. ### Managing the Blast Radius As we move from isolated AI experiments to connected, enterprise-wide systems, risk management is now focused on controlling the impact of failures and keeping operations solid. Managing a single AI model in one process is simple, but running autonomous agent workflows across a whole bank’s systems adds huge complexity. Since regulators insist on human accountability, fully autonomous alert closure is limited by design. AI is used to handle repetitive, low-level data tasks, so human analysts can focus on critical thinking and making final decisions. As a result, compliance auditing needs to move from static code reviews to real-time monitoring of metadata and telemetry. Operational risk teams now track things like system volume changes, processing speed shifts, and how long it takes to close alerts to make sure models stay within safe limits. Safe deployment requires thorough stress testing before launch and immediate response tools, like automated “kill switches,” to isolate agent workflows if something goes wrong. John McGinn, AI Lead for Anti-Financial Crime and Head of Compliance at Deutsche Bank ***{{CARD: "Ensuring Compliance in the Age of AI". LINK: ***[***https://media.nornhill.com/public/pdf/LTW26%20-%20Ensuring%20Compliance%20in%20the%20Age%20of%20AI.pdf***](https://media.nornhill.com/public/pdf/LTW26%20-%20Ensuring%20Compliance%20in%20the%20Age%20of%20AI.pdf)***}}*** *In the next part of London Tech Week 2026, we leave the application and risk layer behind to dive straight into ledger physics, central bank settlement mechanics, the Bank of England’s RTGS liquidity mathematics, and the 0.2-second physical retail gate latency bottleneck.* ### Research on In-House Crypto Processing for Payment Gateways - **Canonical URL**: https://nornhill.com/insights/crypto-processing - **Author**: Nornhill Team - **Category**: Research - **Summary**: The Nornhill team analyzes the shift from speculative crypto to stablecoin utility, evaluating why in-house processing is becoming a strategic necessity for gateway independence and revenue growth. For years, the payments industry saw cryptocurrency as a niche, volatile asset for speculators and managed it as an alternative payment method through third-party processors. That time is now over. Cryptocurrency is shifting from a speculative asset to a stable tool, led by big names in traditional finance. For payment gateways, integrating crypto is now a must. The key question is how to do it, and the answer is to take ownership. This goes beyond just choosing new technology. Payment gateways need to adopt crypto processing to keep growing and stay competitive as the industry becomes more digital. ## The Main Players A clear sign of change is that market leaders are now taking decisive action. Stripe, one of the largest payment service providers, has fully embraced this change. They were the first major fintech firms to support bitcoin payments in 2014. Stripe anticipated the use of stablecoins, and in 2024, they found a partner in an unusual way. [Here](https://www.cnbc.com/2025/02/04/stripe-closes-1point1-billion-bridge-deal-prepares-for-stablecoin-push-.html) is an interesting article on how Stripe and Bridge crossed paths. Take a look. And in February 2025, they acquired the stablecoin platform Bridge. As [Zach Abrams](https://www.linkedin.com/in/zacharyabrams/) put it: "Stablecoins aren't the future—they're already transforming how people move money". Our assessment is that people at Stripe couldn't agree more and are prepared for an aggressive stablecoin push. By May, Stripe announced Stablecoin Financial Accounts, showing they are deeply integrating stablecoin infrastructure. We noted this earlier. > "Stablecoins are common sense. They’re digital dollars that are faster, cheaper and more accessible than the legacy system. We’ve been waiting for this moment for 15 years." Stripe focused on two main domains: AI and stablecoins.One more takeaway from the Stripe Tour 2025. Stablecoins emerged as the unexpected star. Check out our quick rundown on the implications for global gateway infrastructure.[Continue reading on LinkedIn ](https://www.linkedin.com/feed/update/urn:li:activity:7347523451126996992/) Card networks are also evolving. Mastercard and Visa are aggressively building end-to-end capabilities for stablecoin transactions. They understand their future isn't just in card rails; it's in being a network of networks, with stablecoins as a mandatory, integral part of future payments. For example, [Mastercard](https://www.mastercard.com/) has partnered with crypto companies like MetaMask, Kraken, Gemini, Bybit, Crypto.com, Binance, Monavate, and Bleap. These partnerships let consumers access the crypto ecosystem, earn rewards, pay, and spend stablecoins in their crypto wallets using traditional cards. Mastercard is also working with Nuvei and Circle to let merchants receive payments in stablecoins like USDC, no matter how customers choose to pay. This information comes from their [April press release](https://www.mastercard.com/news/press/2025/april/mastercard-unveils-end-to-end-capabilities-to-power-stablecoin-transactions-from-wallets-to-checkouts/). Here is Visa. They launched a new product, Visa Tokenized Asset Platform (VTAP). This platform gives banks the tools and infrastructure to tokenise fiat currencies on blockchain networks. Banks are interested because, at the very least, utilising blockchain as the settlement layer can help facilitate cross-border money movement. So, the point is that when leading payment companies shift direction, it signals a fundamental change in the industry. They are proactively establishing new standards. ## The Regulation The second biggest barrier to institutional adoption is regulatory uncertainty. But this is being addressed. Government authorities are now establishing clear rules for stablecoins to operate as legitimate financial instruments, rather than merely reacting. The UK is an exception, still in the consultation stage. - **Asia** is at the forefront of this movement. In 2022, the Japanese parliament passed a bill recognising stablecoins as a form of digital money that can be issued by licensed banks, trust companies, and money transfer agents. In October 2025, Japan's JPYC was launched as a regulated stablecoin. Also, both Singapore and Hong Kong have implemented comparable legislation. - **The EU** has adopted the Markets in Crypto-Assets (MiCA) regulation, a comprehensive regime with tailored provisions for stablecoins. Notably, [ClearBank](https://clear.bank/learn/news/clearbank-europe-becomes-the-first-dutch-credit-institution-to-complete-micar-notification-to-offer-digital-assets-services-in-europe) recently became one of the first European banks with CASP certification, positioning itself at the forefront of the stablecoin era. - **The United States** signed the GENIUS Act into law in July 2025, establishing the first federal framework for regulating payment stablecoins. - **The UK** aims to be a "global hub for cryptoasset technology". We expect the FCA to introduce its policy by mid-2026, since there was already an update on plans for regulating fiat-backed stablecoins in October 2023. Chronology of major regulatory frameworks This global move toward clarity provides the legal and compliance-grade infrastructure necessary for stablecoins to serve as a bridge between traditional finance and blockchain-native liquidity. In short. Regulation brings legitimacy, and if there are clear rules on how to play, more and more players will play the game, even the most conservative. So it is a matter of time before regulation becomes clearer and clearer. For payment gateways, it's time to act now to stay compliant with all regulations, and major players are already following suit. ## The Market While regulators and institutions implement top-down changes, user demand is driving adoption from the ground up. And this is the most important part: as the market grows, it reveals demand and opportunities for payment gateways. This is also where [Circle](https://gizmodo.com/wall-streets-stablecoin-darling-raises-222-million-to-starve-ethereum-2000757094) is becoming increasingly powerful as a stablecoin issuer, recently raising $222 million to further scale its operations. Here is the stablecoin supply. There is over $217B in circulating stablecoin supply. More than 99% is USD-denominated, and 97% is minted by two issuers, with Tether accounting for 67% and Circle for 27%. Average Stablecoin Supply Supply is growing due to genuine demand. Here are quarterly unique stablecoin active addresses. Yes, the number of stablecoin addresses does not directly correlate with the number of stablecoin users. But sending and receiving address metrics can provide valuable directional insights into activity growth. Quarterly Unique Stablecoin Active Addresses ## Case 1: The Instability-Driven Market Look at Argentina. As highlighted by [Gilles Chemla](https://www.linkedin.com/in/gilles-chemla-aa6b88/), stablecoins account for over 60% of cryptocurrency use. This isn't speculation; it's a real-world hedge against inflation, capital controls, and currency depreciation. Monthly stablecoin trading with ARS ## Case 2: The Explosive Growth Market This instability-driven demand is global. At GR8 Tech, the team has [seen this first-hand](https://www.linkedin.com/posts/ivanvoitenko_crypto-adoption-at-gr8-tech-is-surging-as-activity-7375866639172661248-5F1I). Our internal data shows an explosive **281% year-over-year growth** in crypto users in LATAM and 59% growth in South Asia. The market is pulling us, demanding these payment methods, especially in regions where traditional banking is unreliable. Here is also the [Chainalysis 2025 report](https://www.chainalysis.com/wp-content/uploads/2025/10/the-2025-geography-of-crypto-report-release.pdf) confirming the rise of APAC and Latin America. This adoption is also increasing across both retail and institutional segments. Year-over-year growth rate by region ## Case 3: The Mainstream Consumer This isn't just an emerging-market phenomenon. Here is [Revolut's 2024 annual report](https://assets.revolut.com/pdf/annualreport2024.pdf), which shows following: > "Revenues grew 298% YoY, driven by increased crypto trading activity as observed throughout the industry and the launch of the Revolut X crypto exchange." The consumer appetite is undeniable. There are numerous crypto exchanges, but users typically choose those with which they are familiar or where their assets are already allocated. Visa also sees several stablecoin use cases and opportunities for crypto processors in their [Stablecoins and the future of onchain finance](https://images.globalclient.visa.com/Web/InovantElqVisaCheckout/%7B19dbf03d-4c6e-49d2-9031-8c56e8128aad%7D_stablecoins-and-the-future-of-onchain-finance-2025-Visa-white-paper_5.22.25.pdf) report. - **Remittances.** Global remittances are over $944 billion each year. Traditional cross-border remittance methods to emerging markets are often costly and slow. The World Bank says it costs an average of 6.4% to send $200, mainly due to many intermediaries and high FX fees. Stablecoins, running on public blockchains, offer 24/7 near-instant settlement and transaction fees as low as a cent on some blockchains. They are also borderless and only need a digital wallet. - **B2C Payouts.** The World Bank estimates there are 150 to 300 million freelance workers worldwide. These workers include everyone from carpenters and delivery drivers to designers, social media influencers, and OnlyFans models. Stablecoins offer a new option, allowing fast global payouts mostly in dollar value. This allows freelancers to get paid in a stable, dollar-based asset with near-instant settlement and low costs. At GR8 Tech, our team observes this trend every day, especially regarding B2C payouts. In igaming, payouts are in high demand, and users often choose stablecoins when they have the option to withdraw that way. - **B2B payments.** [Nearly 88% of foreign exchange transactions are dollar-quoted, and 54% of exports are invoiced in dollars](https://www.atlanticcouncil.org/programs/geoeconomics-center/dollar-dominance-monitor/). At the same time, this dollar-centricity makes access to dollars essential for corporates worldwide to operate effectively. However, in emerging markets, obtaining dollars presents significant challenges. These markets are also typically coupled with restrictive capital controls, making access to dollars especially challenging. Stablecoins represent a strategic opportunity to enable more efficient cross-border money movement. ## The Approach For Payment Gateways For payment gateways, the data leads to a clear conclusion: developing in-house crypto processing is essential. Continued reliance on third-party PSPs is not sustainable. - **Independence is key.** When you own your solution, you have full control over funds, settlements, and reconciliation. This removes operational dependencies and lets you serve fast-growing markets more effectively. - **Profitability also matters.** Why pay 0.5-1% in fees to a provider when you can own the infrastructure and reduce costs to less than 0.1%? - **New Revenue.** In-house processing opens up new ways to earn, like balance management and making money from stablecoin reserves through staking or DeFi tools. Remember that Tether and Circle control 67% and 27% of the stablecoin supply, respectively? According to Visa, in 2024, Circle and Tether together made over $7 billion in interest revenue from their reserves. This brings us to the key question: how much does it cost? In an interview with 20VC, Nik Storonsky said launching the product takes 1.5 years for a team of 10 and costs about £2-3 million. Here is Marcel van Oost's post, along with the reaction of 1,500 professionals who agreed with it. It is indeed close to the truth, as our experience and internal projections at GR8 Tech indicate that building a commercially viable crypto processing system from scratch takes at least 3 years (18 months to build and 18 more to commercialise) and costs up to €5 million. Crypto processing budget calculation This is where a "Buy" strategy makes sense. Buying a licensed, operational crypto processor, even at a similar cost, lets a payment gateway launch faster. Our internal analysis shows this approach offers a 6 to 12 month launch window, an experienced team, and a compliant product. The main point is that time is a critical, non-renewable resource that must be used efficiently. ## The Conclusions The "tokenisation of money" is not just a future idea, it’s happening now. Stablecoins are becoming the new fiat. Not only businesses, but academics like Professor Gilles Chemla warn that companies that delay integration risk "being the last coach of the train." Evidence from market leaders (Stripe, Visa), regulators (MiCA, GENIUS), and regular users is compelling. For payment gateways, owning crypto processing is not only a profit opportunity but also essential for future relevance. The optimal time to act was yesterday, so the next best time is now. In any case, as Visa and Mastercard pushes banks that they "needs a stablecoin strategy to be positioned for the growing adoption of stablecoins" the same is applicable to payment gateways. ### The Hidden Drop-Off: How Currency Switching Breaks User Intent - **Canonical URL**: https://nornhill.com/insights/multi-currency-payment-widget - **Author**: Ivan Voitenko - **Category**: Product & UX - **Summary**: Simplifying diverse payment flows can unintentionally break user intent. By maintaining user context and enabling frictionless in-widget fiat to crypto switching, we avoid decision paralysis and drop-offs. Along with tracking transaction volumes, we pay close attention to the Acceptance Rate. Many of you probably do the same. In our industry, AR is a key metric for payment performance. But if we only look at backend success, we miss the main place where users drop off: when they interact with the payment widget. Over the past year, our team partnered with a client to make crypto payments a normal part of their process. We also reviewed payment flows across various methods and currencies. With so many options, it was a complex challenge. That’s why we naturally aimed to unify and simplify these payment flows, and somehow standardise them. However, trying to simplify and generalise in such a diverse payment landscape doesn’t work well. It often results in a lower AR or causes many users to leave right before the key moment — submitting their payment. In 2025, we set out to build a multi-currency payment widget that would let the client's users easily choose their preferred currency and payment method, whether fiat or crypto. By December, we launched the redesigned widget. Our main goal wasn’t just to add features, but to solve a specific problem we found in the data: users losing their intent. ## The Research During our research, we noticed that many users who planned to complete a transaction dropped off before even trying to pay. When we analysed user behaviour, we saw a clear pattern of users restarting the process. If a user wanted to switch from their local fiat currency to a stablecoin or use a different network, the client's old flow often made them leave the widget, change platform settings, and then return. It’s a simple switch, but it happened on the platform, not in the payment widget. In payments, every time a user has to go back a step, the chance they will finish the transaction drops significantly. We realised that making users handle their own context switching was breaking their original intent. ## Designing Integrated ability to toggle between fiat and crypto directly within the widget to maintain the user's momentum To help users move smoothly, our team built the new widget around three main principles: - **First, we ensured the system remembered what the user chose last time.** If someone used a certain currency before, the widget now opens with that already selected. Preserving context. - **Second, in-widget switching lets users change currencies and payment methods without reloading the page.** This way, they can explore options without feeling like they’ve left the transaction. - **Third, we focused on curation over choice.** We prioritised a few stable, familiar options instead of showing every possible asset. This helps avoid decision paralysis, which often leads users to close the widget. ## The Analysis We often say "we are data-driven", but in reality, we might use only about 10% of the data we collect. Even so, that small part helps us stop guessing. This matches a point often discussed in [the McKinsey Podcast](https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/what-does-it-take-to-achieve-and-sustain-growth): > Sustained growth comes not from one perfect strategy, but from careful execution and making the most of the data you have. We appreciate this honesty because it matches what we experience in our work. It is tough to know which project will make the biggest difference, so we focus on the overall results of what we do together with our clients. Since launch, we’ve tracked these changes with detailed funnel reports. We don’t just look at the final "Success" screen, but also watch the small steps users take inside the widget. Analysing the micro-steps within the funnel to see exactly how different payment methods impact the user journey This is an example of tracking user interactions across different levels of friction, depending on the currency used. The screenshot displays a filtered card payment flow, and there are a couple of such funnels to track. We are now using these insights to plan the next phase, to polish the path from the first click to final confirmation, and enhance in-widget switching. Subsequently, we will develop a third phase to introduce new options such as onramp and Wallet Connect. ## A Final Thought for Product Teams As consultants in payments or B2B, it is easy to focus on major client improvements. However, the end user experience and mindset are equally important as technical considerations. Every B2B customer has their own end users to retain. - Leverage your data to identify where users need to backtrack. - Don’t feel you have to reinvent the wheel. Look at how high-volume platforms handle complex choices in simple ways and adopt proven patterns, unless you’re trying something disruptive or experimental. - We rolled this out in stages, using funnel data to test our ideas before each phase. So keep iterating based on your data. Enhancing user flow and preserving user intent can often generate greater revenue gains than solely optimising the gateway’s acceptance rate. ### When 5x Growth Breaks Your Operations Team - **Canonical URL**: https://nornhill.com/insights/redefining-product-operations - **Author**: Ivan Voitenko - **Category**: Operations - **Summary**: When configuration and maintenance tasks jump by 500%, working harder is not enough. Transitioning from manual forms to 'Configuration-as-Code' and self-service Merchant Dashboards ensures scalable growth. In the past 18 months, a major client in the high-risk sector has grown quickly, which has really challenged operations. Since September 2023, our Payment Operations team has been handling five times more configuration and maintenance tasks. If you grow by 10% or 20%, you can just work harder. But when the workload jumps by 500%, working harder is not enough. We have to change how we work. The payments team has reached a point where we can no longer "throw bodies at the problem" but must solve it. Increased PayOps load due to new functionality and clients growth Here’s how we’re moving Product Operations from just reacting to problems to a setup that can grow with us. ## Product Operations Teams To tackle our scaling challenge, we started by looking at the three main parts of our daily operations: - **Payment Operations (PayOps)** is our team of experts for setting up gateways, methods, limits, FX, commissions, MIDs, etc. - **Monitoring** keeps track of our systems using tools like Grafana OnCall and adjusts settings based on success rates. - **The support team** helps end-users by investigating transactions and answering any questions about money movement. In the past, the Product Team focused on clients and end users, while the three operations teams handled all the complexity. Now, we’re treating these internal teams as key users too. ## Delegation as a Strategy Our Payment Operations team was getting stuck, not due to a lack of skill, but because they didn’t have the right tools or had too many micro tools. They were manually setting up features that merchants wanted to manage on their own. So, we created the Merchant Dashboard. This is more than just a new interface, it’s a big change in who does what. By adding self-service features, we’re shifting about half of the PayOps work to the client, including configuring payment methods, merchant IDs, routing, and the appearance of the payment widget. - **In 2025:** Merchant requests a limit change → Ticket created → PayOps manually updates config → PayOps notifies Merchant. - **In 2026:** Merchant logs in → Merchant updates limit → Done. Managing payment methods in the Merchant Dashboard This 'Configuration as a Service' approach lowers error rates, helps merchants launch faster, and lets our PayOps team focus on more complex work instead of routine tasks. I hope this works out, since it can be tough to convince clients that taking on these tasks themselves is actually a benefit, not a drawback. ## Beyond Configuration Real Product Operations means the software helps take care of itself. We’re bringing this idea to our Monitoring and Support teams too. For Monitoring, we’re moving past just watching what happens. The payments team built a central dashboard to manage all gateways, payment methods, currencies, and MIDs in one place. Now, the monitoring team can respond to and update clients in minutes, rather than handling each client and project separately. We’re also giving clients a similar interface, so they can react to Grafana metrics right away and switch payment methods by MID or country in real time. Some mature clients are interested in this because they have their own operations teams. For Support, we connected our product directly to Jira Service Management (JSM). Automating transaction lookups and status updates means support staff spend less time searching for answers and can help users faster. With less routine work, our team has taken on more tasks and is now focusing on fraud prevention. That’s been great. This isn’t AI, it’s just making daily work easier through automation. ## Focus in 2026 to make Operations as an Enabler We’re changing PayOps from just managing configurations to helping the company grow. By giving clients more control and automating the tricky parts of monitoring and support, we make sure our costs don’t rise as fast as we grow. Some projects are already finished, and the results are encouraging. That’s why the Payments Product Team keeps rolling out the Merchant Dashboard and other tools to automate daily work. ## One More Challenging Idea While the Merchant Dashboard helps clients handle more on their own, I’m also rethinking how we manage complexity and planning to move to the so-called 'Hybrid Configuration' model. I was inspired by [Thought Machine's](https://www.thoughtmachine.net/vault-core) simple and effective 'Smart Contracts' for core banking, and I want to use a similar approach in Payment Operations. Yeah, these guys are far beyond payment hubs, but the way they deal with times more complex products is truly amazing. So, back to our core infrastructure, here is the idea. - For Merchants, we’ll offer a simple, self-service interface to handle 60-80% of their daily tasks. - For PayOps, we’re moving from clicking through lots of forms and checkboxes to using Configuration-as-Code. This means PayOps will handle complex setup, like routing, through version-controlled files in YAML or JSON, instead of working through the back office. Here is just an example of possible config files to better understand what "Configuration-as-Code" is. ``` # CONFIGURATION: MGM Entertainment (Brazil) # PROJECT: "The Biggest River" currency: "BRL" # 1. PROVIDERS active_providers: - "PagBrasil" # Primary for PIX - "EBANX" # Primary for Cards # 2. LIMITS & SEGMENTS # VIPs get higher limits; New users cannot use Credit Cards (Risk) user_limits: new_user: max_amount: 500 allowed_methods: ["PIX", "BOLETO"] # No cards allowed vip_user: max_amount: 100,000 allowed_methods: ["PIX", "BOLETO", "CREDIT_CARD"] # 3. DEFAULT ROUTING # Automatically manage traffic without waking up an operator routing_rules: - rule: "Performance Failover" logic: | IF PagBrasil.success_rate < 85%: THEN switch_traffic_to "EBANX" - rule: "Cost Optimization" logic: | IF payment_method == "PIX": THEN route_to "PagBrasil" (Lower fees) ``` Will this change really transform PayOps, or will we get stuck halfway? I’ll share more about it later. ### Why Your Payment Gateway Isn't an Orchestration Platform Yet - **Canonical URL**: https://nornhill.com/insights/payment-orchestration-strategy - **Author**: Ivan Voitenko - **Category**: Architecture - **Summary**: Transitioning a basic payment gateway into a multi-region orchestration platform requires a layered approach: Unification, Core routing loops, Risk & Compliance, Intelligence, and Self-Service. Transitioning a basic payment gateway into a multi-region orchestration platform requires a layered approach: Unification, Core routing loops, Risk & Compliance, Intelligence, and Self-Service. In 2023, the company shifted from B2C to B2B, offering our platform to other clients to test if this business model could last. Three years later, the decision paid off, thanks to a lot of hard work from everyone, especially the Payment team. For years, clients, management, and the industry saw a Payment Gateway (PG) as just a technical tool. A way to connect merchants to payment providers and move card data. It was seen as a simple pipe that just needed to be big enough to handle peak traffic. But today, PG is a high-volume, multi-region payment system, and calling it a utility no longer fits. Our PG has been more than just a gateway for a while. It has quietly grown and changed: - 130+ integrations and 170+ payment methods. - 3.6M unique users across 40+ countries. - 18M transactions monthly with nearly 0.04% of chargebacks (yeah, such a low rate because of diverse LPMs, bank transfers, and crypto) - 500+ monthly configurations of client brands. Dozens of bespoke merchant configurations per brand, per country, per product. Indeed, now, PG does more than just move data. PG handles complex operations. Let's look at the strategy that came out of our operational challenges and how it helped us focus, deliver, and grow into a Payment Orchestration Platform. Product planning and prioritization representation ## When Product Operations Reached a Breaking Point It might sound odd, but success brings its own debt. What made me rethink PG strategy wasn't new technology, it was the pain of daily operations. As we grew, our manual workload piled up. Over two years, our operations backlog grew five times. The more clients we brought in, the more our top Product Operations (ProdOps) team got buried in configuration tickets, manual routing, and custom setups. #### Related Insight When 5x Growth Breaks Your Operations TeamRead how we transitioned from manual forms to Configuration-as-Code and self-service dashboards.[Read Article](/insights/redefining-product-operations) I realised we were running a complex, maturing system, but still treating it like a simple pipeline. So, the Payments team stopped focusing solely on a Gateway, its features, and occasional fixes and started planning for a Payment Orchestration Platform (POP). Here's how I defined that change, assessed our situation, and created a roadmap to turn our operational pain into product strengths by 2026. ## Self-evaluation and Aspiration You can't plan for a system unless you can describe it clearly. I stopped talking about a list of features and instead defined the POP in clear layers. To explain it, you need to know your product and understand where it is in its development. You also need a clear vision of where you want to go. For me, that meant comparing our Payment Gateway (PG) to a Payment Orchestration Platform (POP). There are many opinions and discussions about PG and POP. On LinkedIn, you might see posts from people who compare PG and POP or share related content. Other well-known companies also talk about the need to change payment gateways. These resources are a good starting point, but as a payments product manager, it's important to understand the differences yourself. Most services make Payment Gateways seem less complex than they are and often exaggerate what Orchestration Platforms can do. That's just how marketing and sales work, and sometimes these comparisons get a bit ridiculous. So, always start with your own situation. Don't overlook the strengths and services your product provides. In payments, few people talk about important topics like reconciliation, how money moves in RTGS, or clearing and settlement. Most articles just cover card payments, processing, and surface-level topics. Stories you can tell your kids to explain what you are doing. Getting back to the main point. Once I had a clear vision, I described each layer and its services. This approach worked well for me. - **Unification:** The single technical entry point (APIs and integration adapters). - **Core:** The brain of orchestration (payment methods, merchant accounts, routing, cascading). - **Risk & Compliance:** Fraud prevention rules, vaults for sensitive data, tokenisation services, segmentation, and regulatory hooks. - **Intelligence:** Reconciliation, FX, fees, balances, settlement data, reporting, and even monitoring. - **Self-Service:** The Merchant Dashboard, no-code builders, and configurations of the payment widget. After that, management stopped asking if we had certain features and started asking which layer was limiting our scalability. I did an honest review of our platform, rating each layer as Strong, Basic, or Weak. This wasn't for management (it was mainly for me), and I even underestimated some areas to better explain things to the C-level team. For example, our Unification layer is Strong because we integrate quickly and handle large volumes. But our Self-Service layer is Weak since we depend too much on the ProdOps team to set up routes and settings manually. Many services, like reconciliation and fraud prevention, are at a basic or decent level. The real bottleneck isn't the code (okay, mostly it isn't). It is the delegation. ## The Narrative To address this complexity, I required more than a simple feature list. I needed a clear narrative to guide our team over the next 12 to 24 months. I structured the roadmap around a three-phase progression: Orchestrate, Delegate, Monetise. The process begins in 2026 with Orchestration. The immediate objective for the payments team is to transition decision logic from static configuration files to a dynamic visual builder. The team is developing engines to manage payment service providers (PSPs) and payment methods across regions, experiment with payment flows and retry strategies, and enable direct user interaction through the payment widget. These capabilities allow acceptance goals to be set without requiring code modifications. Once these engines are stable, the focus in the second half of the year shifts to Delegation. At this stage, manual configurations are transferred from internal back-office systems to the Merchant Dashboard. The guiding principle is that merchants should have the autonomy to adjust limits or toggle providers independently when it is safe to do so. This approach applies to every aspect that merchants can handle themselves, from simple payment method switching to routing, smart retries, and even chargeback management. By 2027, this progression positions us to Monetise. With a mature platform established, we can transition client discussions from offering basic "payment processing" to delivering "payment performance", emphasising guaranteed outcomes and revenue recovery. ## The 2026 Focus A strategic narrative remains theoretical until it is translated into actionable work. To bridge the gap between my high-level vision and the operational realities of our teams, I narrowed the H1 2026 focus to three specific Objectives and Key Results (OKRs), each with clearly defined quarterly outcomes. Typical Gantt charts are still actual and very helpful to focus teams on projects and clients on outcomes We are overhauling the Payment Widget not only to update the user interface, but also to support complex new flows such as Fiat-to-Crypto on-ramps. Concurrently, we are deploying Card Cascading (aka Smart Retries) as a controlled experimental environment to demonstrate that intelligent retries can generate measurable revenue increases. Most importantly, we are systematically migrating high-volume manual tasks from internal queues to the Merchant Dashboard. ## Why Definitions Matter Understanding customer needs is essential, and delivering the right products is our responsibility. However, it is even more important to define what the final product should be in the next 12 to 18 months (not in 3-5 years), rather than getting lost in ongoing feature requests. Evolving into a Payment Orchestration Platform goes beyond renaming or updating our appearance. This transition reflects a real change in our positioning. Since it includes many services, complex logic, operational processes, and a team of 100, its impact is significant. By addressing weaknesses, we position ourselves as an Orchestration Platform, enabling us to grow from a business unit into a comprehensive business entity with its own merchant base. At the same time, the company gains a significant asset that provides a unique value proposition and competitive advantage in an industry with limited differentiation among providers. I chose to share this roadmap transparently with our clients to strengthen our relationship. We are not just promising new features; we are aligning on an evolving operational model. Merchants now see the payment gateway as a sophisticated platform, which supports a higher willingness to pay. So, the question for product people managing infrastructure is whether they are operating their systems based on historical models and clients requests or actively building for their current and future state.