Conf42 Machine Learning 2024 - Online

Card Payments Lifecycle Explained

Video size:

Abstract

Unravelling the card payment process from swipe to settlement

Summary

  • Today we'll be exploring the various components and processes involved in card payments. We'll also look at the role of machine learning in the domain. Michael is a software engineer who has worked in several sectors of the payments industry.
  • There were over 600 billion transaction volumes per annum from card payments. This amounted into $4.2 trillion in spending annually. However, there's also a substantial $30 billion loss to fraud every year. Here are some of the main components and parties involved in the card payment ecosystem.
  • Customers interact with the card by tapping their card on the terminal or entering their card details on a website. After that, the next thing the customer says is whether the transaction is approved or declined. This includes authorization, capture, settlement, reconciliation.
  • The cardholder initiates the transaction when they want to pay for some goods and services. The merchant sends that request to the acquiring bank. Next step is capture, where the money is frozen from the cardholders account. If successful, the bank would then send a successful response all the way back.
  • In some countries, you tap your card before you buy the fuel. Also, when you go to hotels, for example, you make payments. Every merchant has a limited amount of time to send capture request. If you don't capture within seven to 15 days, then the transaction is reversed.
  • There's over $30 billion per year in fraud loss. Machine learning can be used for fraud detection and prevention. For customer experience, machine learning could be used to personalize the authentication experience. But there are still several challenges, including regulatory compliance.

Transcript

This transcript was autogenerated. To make changes, submit a PR.
Hello, everyone. Welcome to this presentation on demystifying the card payment lifecycle. Today we'll be exploring the various components and processes involved in card payments, as well as the role of machine learning in the domain. First, let me introduce myself. My name is Michael. I'm a software engineer. I began my professional journey in 2014 and over the past decade I've had the privilege to work with leading companies in several sectors of the payments industry. My experience actually in payments spans across a wide range of sectors, from working with a smart data, smart card data personalization company where we embed EMV data into payments card chips, to payment processing, fintech issuer banks and so on. And for me, it's been a very exciting journey. I hope for you either you are looking to move into the payment industry or you're already within the payment industry. It will also be an exciting journey for you. All right, so before we go into all of the things about the payment lifecycle, I thought to share some stats to even let you know. Why is it even important to want to know what happens with payments or with card payments? Basically, first, as of 2022, and this number has increased drastically, but I couldn't get the more recent stats. There were over 600 billion transaction volumes per annum from card payments and this amounted into $4.2 trillion in spending annually. That's a huge sum of money. However, unfortunately, there's also a substantial $30 billion loss to fraud every year from card payments also. So let's identify some of the main components and parties involved in the card payment ecosystem. The first and foremost is your, you know, the actual payment card itself. That's the card that your bank or your financial institution issues to you to be able to spend from your account, right? And this could be a physical card that you tap or swipe at a pure point of sale terminal or a virtual card which could be on your wallets, on your phone and so on. And these cards generally or typically contains a 16 to 18 digits number in front of them, which is called the pan or the primary account number. Next component is the cardholder, which is you. This is pretty much straightforward. If you have a payment card, you are a cardholder. So basically you're the person who initiates transaction using the card by swiping, tapping or entering your details online. The next component is the issuer or the issuing bank. Now this is the bank that the cardholder has an account with, and that's the bank that has issued the card to the cardholder. Next we have the card scheme or card network. Usually these are companies like Visa, Mastercard, American Express, you know, China Union pay, and so on. They facilitate transactions between issuers and acquirers. Usually this, the card you get issued by your bank would have the logo of who the card network is or the card scheme. Next is a merchant. The merchant actually is a business itself that is accepting card payment for goods and services. This could be Tesco, Sainsbury, Amazon, name it. It could be a physical store merchant or an online merchant. Next is the acquirer bank and the acquirer bank, or the acquiring bank, or the acquirer is a financial institution that actually processes card payment on behalf of the merchants. Usually the acquiring bank is the bank where the merchants have their own bank accounts, you know, so if you think about you as a cardholder having your bank account with the issuer who issues you a card, then the acquiring bank is the bank where the merchants typically have their own account. And typically the acquiring banks provide the terminals that merchants, especially fish, scout store merchants that need point of sale, like PoS terminals. Usually the acquiring banks provide. Not always, but usually provided by the acquiring bank. Those terminals, last but not the least, is the payment gateway or payment processor. These usually have technology providers that help securely transmit transaction information between the merchants and the acquiring bank. In most cases, these are more likely to be used for online transactions, and if the merchant has the technical capability or expertise to be able to do this, payment gateways are not necessarily involved in card payments. Transaction flow all right, that was a lot. Please feel free to come back to watch this part over again as necessary if you missed anything in the first go. So what do customers see when they make card payment? Right from the customer's perspective, they interact with the card by tapping their card on the terminal or entering their card details on a website. And they either get an optional, like verification or authentication step in the old flow, which could be asking for Pin or three deciseconds. And after that, the next thing the customer says is whether the transaction is approved or declined. So you either see that on the POS terminal, or maybe you are redirected to a new page, the success page on the web portal for the merchant. And that's it. You done? Payment done as far as the customized concern, right? Looks easy, right? Like my daughter would say, easy peasy. Well, not quite easy for the customer, which is good, but not so easy for other parties involved because there are a lot of other processes behind the scene that actually take place, you know, and this includes authorization, capture, settlement, reconciliation. We'll be talking about this in detail. One after the other. So starting with authorization, you know, this is actually the process that was described in the previous slide where the cardholder initiates the transaction when they want to pay for some goods and services. You tap your card or, you know, enter your card details, and then it initiates the authorization request flow. So basically, what's the authorization request flow? We can see from the diagram. The first step in the authorization request flow is that the cardholder swipes their card, tap their card, enter the card details, whatever initiated by the cardholder, the merchant receives this and then sends this request to the acquiring bank, either directly or again through a payment processor. The merchant sends that request to the acquiring bank. It's called the authorization request. Now, the acquiring bank looks at this request and based on the PAN, the first few digits in the PAN, it identifies what issue, I'm sorry, what card network the request should be routed to. And this could be either visa, Mastercard or American Express. And once this request is sent to the card network, the card network itself, then based on the first six digits of the PAN, determines, actually six digits of the PAN is called the biN. That's a bank identification number, or IIN, which is the issuer identification number. So based on these first six digits, the card network determines what bank or what financial institution issued that card and then they send a request to that financial institution. And this could be bank of America, Citibank, or it could even be one of the fintechs like wise revolutes and so on. Right. Then the Ishwa bank performs a number of things which could be include balance check, to be sure you have sufficient funds to pay for what you're trying to do. Fraud check. You know, to prevent fraud, there's also transaction limits, checks, right? Have you gone over your daily limit, your monthly limits, you know, and any other transaction rules that apply once all of this is done, if successful, the bank would, the issuing bank would freeze that fund from the cardholders account and then send a successful response all the way back. So sends the response back to the card network, the card network sends it back to the acquiring bank. We then send that response back to the merchant. And then you see you as a cardholder, you see the result on either the terminal or you get redirected on a website to the successful page that the transaction is done. So again, mouthful, this is everything that goes on. Well, when I say everything, even still on a high level, because there are a lot of other things that issuers could do in the background and all of that. But, you know, this is like an overview of the process and what happens when authorization takes place. Now, next would be capture, right? Because when a transaction takes place, the money is frozen from the cardholders account. However, the merchant doesn't have the money yet. The money is still technically with the issuer, actually with the issuer. But somehow the issuer knows that they owe some form of money to somebody, right? So the next step that comes here is at the end of the day, usually, not necessarily all merchants do this, but usually at the end of the day, sometimes it might take two days, three days. Merchants then compile a list of transactions that they've sent for authorization on that day and send it as a batch request to their acquiring bank, right? The acquiring bank takes this batch request and then splits it, categorizes it according to Whatcard network. Because take for example, an Amazon or say, Tesco. Hundreds and thousands of people paying every day would definitely have paid with different cards issued by different banks and which have different card networks. Could be Visa, Mastercard, American Express, right? Usually Visa, Mastercard in the UK. What the acquiring bank would do in this case is further categorize or split that request into two. In this case, Mastercard and Visa request send one to Mastercard and send the one for Visa to Visa, right? Once that request is sent to those card schemes, the card scheme themselves, or the card network would then say, in this example, I'll just go ahead with the Visa. Say Visa receives that request from the acquiring bank. Visa then further splits the request based on. Because this could be, again, say, hundred transactions and 50 of them could have been from cards issued by bank of America or 30 of them from banks, from Citibank, you know, 20 from HSBC or wise, you know, and so on. So the scheme splits this and then send the request to the capture request to all of those financial institutions. Now, what the financial institution would do is they received a request and then they try to match each capture record to a transaction that they've previously authorized. Right? To show that, okay, we've authorized this transaction before to freeze this money. Now we are confirming that this transaction is completed because the merchant is now asking that they would be collecting this money, right? So that happens. Now, for some banks, the user experience is usually different. For some banks or for some financial institutions, when you initiate a transaction, you see the transaction with the status of pending. And when capture actually happens, the status changes to completed. While for some other banks, when you, they show this to you in a way of showing you two different balances, you could have an available balance and a book balance or booking balance. Available balance is the amount you have to spend, which usually is less than the booking balance, because available balance would be booking balance minus any pending money that needs to go out. So, yeah, so that's how capture is then done. And still there's no money movement in capture. That just confirms that the merchant has stated their intent to, you know, capture this money. To collect this money, there comes settlement, which is the step four of the diagram. Right. The issue bank will then initiate after receiving settlement requests, usually, sometimes through the card scheme, initiates the actual money movement by paying this fund, maybe to the card scheme or directly to the acquirer bank, and then the acquire bank would then settle their merchants. And yet again, this process, even though it's technically the end of the card payment life cycle, there's still reconciliation that has to be, or that needs to be done by some of these parties, especially the issuer bank. You need to confirm that the money that was paid in and the money that is paid out actually matches. Right. So what do I mean by that? There are several types of transactions that could happen in a day. You know, you could have authorization requests, could have reversals. You have chat box, you have fees. It's even more complicated or more complex if you have multi currency transactions. Right. You would need to. A transaction could be done in one currency, and the settlement is done in a different currency. Companies have to implement very sophisticated functionalities or very sophisticated systems to actually do reconciliation. Reconciliation, as far as I'm concerned, is, like, the most difficult, the most daunting part of this whole process. Not to say orders are simple. Mostly, they require speed. When I type my card, I need to get a response as soon as possible as to whether it's successful or not. I don't want to wait too long. Every other thing is, it happens in the back end. And for some of these, they are very computationally heavy. So that's why I consider it one of the most, you know, daunting parts or the one of the most complicated parts of this. And just before I move on, you know, one reason why this is very. You know, why it's a very daunting task is that in addition to all of the types of transactions I've mentioned here. Right. You could have something. We have something called preord. I didn't want to go too much into this, but we have something called preord. Right. And basically, imagine when you go to a gas station to buy fuel. This doesn't happen in every country anymore. In some countries, you tap your card before you buy the fuel. So gas station actually like, sends authorization requests to reserve a certain amount. This could be say 100 pounds, and then you end up buying fuel. And you might just buy foil for 60 pound and then there's a 40 pound difference. When they send the captcha to the issuer, they are going to be capturing the actual amount of the foil you bought, which is 60 pounds. And again, this is going to reflect the, the issuer would have authorization request, which is 100 pounds. And then when they get the capture request, it's 60 pounds. They need to be able to identify that this is the same transaction. Also, when you go to hotels, for example, you make payments, or sometimes they reserve some money just in case of damages and of that, which brings me to the point of where after authorization is done, every merchant actually has a limited amount of time to send capture request. Otherwise that transaction would be reversed or cancelled and the money will be refunded to the customer. So even though you provided the service and the person has gotten either the goods or the service, if you don't capture within, I think there's for pre authorization and authorization, you don't capture within seven to 15 days, then the transaction is reversed and that's it. You have no legal rights to, or the customer has legal rights if you try to capture their money to tell you that it's now their money. So, yeah, maybe something not to note, but yeah, so that's on what actually really does happen. So where does ML come in in all of this? First is fraud detection and prevention. Right. We already said earlier that there's over $30 billion per year in fraud loss. Usually all of the parties involved, the issuer bank, the card scheme, or the card network, the acquire bank, usually have some form of fraud detection or fraud prevention systems or mechanisms, right. And usually these systems are more efficient if you have some form of machine learning models that are learning new tactics that like basically getting new ways to identify what could be a fraudulent, or detect what could be a fraudulent transaction. Next is, yeah, again, it's very similar to the previous, but in this case, identifying transaction data discrepancies. Right. This is not necessarily used for fraud, which is why I've separated them. Right. You might be using this to maybe in your settlement flow or, or something just to, you know, either rather than waiting for human to find out that something has gone wrong somewhere. Because a lot of things go wrong when it comes to payment authorization, capture, and, you know, settlement reconciliation. You could use machine learning to at least help you automate and suggest, you know, it helps you debug in sort of a way and shows you, hey, I think this could be wrong. And then you can then go and find out if it's truly wrong or not. Next is predictive analysis, right. If you are an issuer, that you're global, if you're a global issuer, meaning your cards, which is actually the case for most issuers or for most banks, if you really want to try right now, in this day and age, your cards will be used internationally, right. This means that there would be multi, multiple currencies you might need to settle in, pounds, in USD, name it, swedish krona, and so on. And this could translate into you having multiple bank accounts where this liquidity would be just to have pounds to be able to settle and all of that. Now, this is one of the most. One other part that is very challenging for, I would say, especially the treasury team of these companies, where you need to know whether you should owe more pounds or more USD. And this could depend on what are the interest rates on these currencies or what's the fluctuation, like, how the volatility of the currency and all of that. Machine learning could be used to help at least try to narrow down how much, approximately you need to hold in that currency for settlement. And last but not least is customer experience. For customer experience, machine learning could be used to personalize the authentication experience. You could understand what kind of authentication method the customers prefer to use the most. You could use this to customize rewards and promotion based on the kind of transactions that the cardholders are executing and or initiating. And lastly, you could use, this is used in some form of credit scoring and risk management. So, yeah, those are some of the main use cases of machine learning. Of course, machine learning is used in a lot more places in payments, but the list will go on and on. But there are still several challenges, because I'm not sure if there's been some bells ringing when I was mentioning the last set of use cases for machine learning, which involves things around customer data. Right. One of the challenges is data privacy and security. Now, this goes in several ways. It could be, I like to say something that where there's money, there's tendency for fraud. So in terms of security, you need to ensure that customer data is secured. And of course, you also need to respect the privacy of, you know, those customers. Right. Customer data has to be secured. Even if you have any system, either machine learning or AI or whatever, any other system that you use in dealing with customer data, it has to be secured so that you don't expose sensitive cardholder information. And also, in most cases, which we'll still talk about a bit later on, it has to also adhere to regulations such as GDPR, PCI and all of that. We've seen that machine learning models can introduce bias, leading to unfair treatment of certain groups. It's really essential to monitor and mitigate this bias to ensure fairness. And lastly, which I already entered on in the first is regulatory compliance. I mean, it's not surprisingly, the payments industry is highly regulated, with different regions actually having varying or different compliance requirements. Right. And organizations need to navigate these regulations carefully to avoid penalties or reputational damages. So what other way to try to end this presentation than to, you know, make some, I don't know, keep the room light, right. You get AI, you get AI. Everybody gets AI. We've seen that AI is becoming more and more injected into a lot of industries and the payment industry is not exempted from that. A lot of products, a lot of features, a lot of these things that are manually done would have very good use cases for AI to come in in the nearest future. So keep an eye out on that. And yeah, thank you for listening. I hope that you actually gained a clearer understanding of card payment lifecycle, the role of machine learning in terms of improving efficiency, security and improving customer experience, and also the future trend in terms of where we think AI might be used.
...

Michael A Johnson

Software Engineer @ Meta

Michael A Johnson's LinkedIn account



Join the community!

Learn for free, join the best tech learning community for a price of a pumpkin latte.

Annual
Monthly
Newsletter
$ 0 /mo

Event notifications, weekly newsletter

Delayed access to all content

Immediate access to Keynotes & Panels

Community
$ 8.34 /mo

Immediate access to all content

Courses, quizes & certificates

Community chats

Join the community (7 day free trial)