Blog article
See all stories »

The Hidden Complexity Behind a Simple Bank Payment

As a regular consumer, you might not realize that a simple wire transfer to a company or a friend launches a complex and lengthy payment flow. This process involves multiple financial institutions and diverse IT systems. In this blog, we explore a typical payment flow at a financial institution.

The complexity of the payment flow stems from increasingly strict regulatory requirements designed to mitigate risks to the financial system and reduce financial crime. Additionally, the high non-functional requirements for payments — such as reliability and security — are critical for maintaining customer trust in the financial system. This necessitates intricate architectures with numerous optimizations and redundancies to meet these stringent requirements.

Large Tier 1 banks process millions of payments daily, where even a failure rate of 0.001% results in hundreds of failed payments per day. With the rise of digital payments, instant payments and regulatory complexities, the payment flow has become ever more critical, operating 24/7. Tight performance constraints (like the EU’s 10-second rule for instant payments), increasing volumes, and stringent regulations present significant challenges for financial institutions.

Therefore, it is crucial for financial institutions to continuously analyse, document, and monitor their entire payment flow to understand its complexities, performance bottlenecks, and dependencies in near real-time.

A typical payment flow in a bank can be divided into three operational layers and two supporting layers:

  • Operational layers:

    • Payment Initiation & Acceptance: The payment journey begins with the customer initiating the payment through various channels, such as mobile or internet banking, ATMs, or scanned paper wire transfers. Initial controls occur at this stage to inform the customer immediately and allow for corrective actions.

    • Payment processing: Additional controls and payment instructions are generated here. Instructions may be routed internally (for intra-bank transfers) or externally to market infrastructure players, other banks, or networks like SWIFT.

    • Clearing & Settlement: This stage ensures the proper transfer of money between the involved financial institutions.

  • Supporting layers:

    • Analytics & Monitoring: This layer analyses and monitors payments, typically separated to avoid impacting the operational flow during complex analyses.

    • Corrections and Investigations: This layer provides tools to identify, investigate, and potentially fix operational payment issues manually.

Each of these layers can consist of multiple applications, all providing specific features.

Payment Initiation & Acceptance

This is where the journey of a payment begins. In this stage, we can identify four main actions:

  • Initiation: Payments can be initiated by providing wire transfer details, direct debits, scanning QR codes, clicking payment links, etc.

  • Authentication: Verifying the customer’s identity to ensure the correct person initiates the payment. This may involve single or multi-factor authentication depending on the bank’s policy and risk level of the payment.

  • Authorization: Ensuring the authenticated user has the necessary authorization to execute the payment, including checking mandates and required signatures.

  • Validation: Early validations to reject payments as soon as possible if there are issues, such as incorrect account numbers or insufficient funds.

Payment processing

This core layer involves multiple systems and functions, including:

  • Payment Execution

    • Payment Validation: Revalidating payment details and authorization, and checking for duplicates.

    • Payment Enrichment: Adding additional information, such as debtor address details and BIC codes. Some information returned by the "Payment Risk & Compliance Management" and "Accounting and Account Management" modules is also used for enriching the payment data.

    • FX Handling: Managing foreign exchange for payments involving different currencies.

    • Calendar Service and Cut-off management: Calculating execution dates based on global holiday and business calendars.

    • Message Transformation: Converting payment messages to required formats.

    • Prioritization and Routing: Assigning priority and directing payments based on various factors.

Several vendors offer packages for these features, like FIS OPF, Finacle Payments Suite, Fincentric, FiServ, Mambu, Oracle FLEXCUBE…​

  • Payment Risk & Compliance Management

    • Exposure Limits: Ensuring payments do not exceed predefined limits.

    • Fraud Engine: Detecting and preventing fraud. Several vendors offer services for this, like Featurespace, Fraudio, NetGuardians, ComplyAdvantage, Feedzai, Fraud.com (aiReflex), LexisNexis Firco, Everlink, Trulioo, Slope, Quantexa, SAS Comply, NICE Actimize…​

    • KYC (Know Your Customer) Engine: Verifying customer information and assessing risk. Vendors offering KYC engines are Veriff, Know Your Customer, Apt-Pay, Trulioo, Shufti Pro, Fractal ID, Sumsub, IDology…​

    • Sanction Screening: Checking involved parties against sanctions. Examples of package tools offering this service are Sanction Scanner, FOCAL, ComplyAdvantage, SEON, Alessa…​

    • Verification of Payee: Confirm the payee’s identity and compare with the name and/or address provided by the payer. This can be done through services like Surepay, Nium, AccessPay…​

    • AML (Anti-Money Laundering) engine: Monitoring payment transactions for money laundering activities.
      Platforms like Ripjar, ComplyAdvantage, LexisNexis, Vespia, Discai, Veriff, Alloy, Onfido, Greenlite, Oracle AML Transaction Monitoring…​ offer this kind of service.

    • Internal Fraud Verifications: Detecting internal fraud.

    • Treasury Management engine: Ensuring sufficient liquidity across all bank accounts (at correspondent banks, market infrastructure players and Central Banks) to meet settlement obligations.

    • Accounting and Account Management

    • Accounting Entries: Recording transactions in the ledger.

    • Account Balance Management: Create transactions and corresponding credit/debit movements on the accounts and update the balances accordingly.

    • Fee & Tax calculation: Calculate the fees and taxes involved in the payment transaction.

Clearing and Settlement

This layer involves secure connections with networks and market infrastructures and ensures compliance with specific communication formats and rules. It also includes fail-over mechanisms to reroute payments in case of issues.

Examples of networks and MIs are SWIFT, SIC (SIX), US FedNow (Federal Reserve), US RTP (The Clearing House), P27, MYRPP, Fedwire, CHIPS, EURO1/STEP1/RT1 (EBA Clearing), T2/TIPS (Eurosystem), CHAPS (Bank of England), NACHA, EFT, BACS/FPS (Pay.uk), CORE (STET)…​

Examples of formats are ISO 20022 (with different flavours, cfr. my blog https://bankloch.blogspot.com/2024/05/unifying-payment-systems-embracing-iso.html), SWIFT MT (ISO 15022), ISO8583, Standard 18 file format, NACHA text file format…​

Several solutions are available on the market for this layer, such as SWIFT SAA/AMH, Intercope BOX, Prowide Messaging Hub, Bottomline MessageManager, Volante Technologies, Finastra Total Messaging…​

Analytics and Monitoring

This layer enables analysis and monitoring for purposes such as anomaly detection, regulatory reporting, SLA monitoring, and real-time flow monitoring.

The layer consists of following features:

  • Record keeping: banks are legally obliged to keep records of all payments for an extended period, often 10 years. These records should be easily accessible for regulatory or customer inquiries.

  • Analytics: analysing payment data for insights.

  • Regulatory, Legal and Fiscal Reporting: generate certain regulatory reporting on payments, like recurring reporting on payment volumes, reporting of transaction which missed cut-off time, reporting on metrics of instant payments, reporting on foreign transactions for governments to identify VAT fraud…​

  • SLA management: monitor internal SLAs in the payment flow, but also SLAs agreed with MIs and correspondent banks.

  • Business Activity Monitoring: continuous, real-time monitoring of the payment flow, allowing to have continuous view on the volumes and value at risk. Additionally, the system should pro-actively alert the operations team (or any other team) in case of anomalies with the payment flow.

The Intix Transaction Data Platform offers all above features, offering a comprehensive platform for real-time payment transaction data insights and effectively tracing, tracking, and understanding payment transactions.

Corrections and Investigations

This layer provides necessary tooling to intervene on certain problematic transaction. It typically includes functionalities like:

  • Payment Repair: Fixing errors in payment details.

  • Manual Corrections and Exception handling: Addressing issues that automated systems cannot handle.

  • Case Management: Handling exceptions and disputes.

  • Reconciliation and Corrections: Balancing and correcting account entries.

Obviously, most of these features and layers also need to function in the opposite direction, i.e. when the financial institution receives a payment from another financial institution. In that case the flow will be in the opposite direction, but similar activities are also executed by the receiving financial institution.

The above shows that the journey of a simple bank payment is far from simple. It involves numerous steps and systems working together to ensure your money gets from point A to point B quickly, safely, and accurately. Understanding this process is crucial for maintaining a payment flow that meets the highest standards today and in the future.

For more insights, visit my blog at https://bankloch.blogspot.com

 

3603

Comments: (1)

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 11 June, 2024, 14:031 like 1 like

Nice post.

Very few people realize that a typical 2FA credit card payment in India has 14 moving parts and the payment is successful only if all them work in concert. While the owner of each moving part might pat itself on the back for being up and running 95% of the time, the success rate of the end to end payment is only 0.95^^14 = 49%. In other words, a majority of payments would fail even if each hop has 95% success rate. 

Another thing many people - including many fintech founders - don't get is that the everyday transaction in other industries happen within a company's boundaries whereas even the smallest of payments traverses multiple companies, and that there's really no central system to orchestrate all of those systems.

Joris Lochy

Joris Lochy

Product Manager at Intix | Co-founder

Capilever

Member since

05 Apr 2017

Location

Brussels

Blog posts

127

Comments

19

This post is from a series of posts in the group:

The Payments Business

Share opinion and experience on how the payments landscape is changing and learn about the challenges and opportunities facing payments stakeholders in the future.


See all

Now hiring