-

Evolving Insurance

06 February 2020

Our regular Evolving Insurance calls can connect your business with the latest in regulation, technology and insights, allowing you to be at the forefront of the industry. Discover our recent sessions below.

Payment Acceptance Optimisation

PAO relates to credit and debit card transaction acceptance rates, ensuring genuine transactions are accepted, whilst preventing opportunities for fraudulent transactions. Listen below to find out more.

Gavin: Hi and good afternoon, everybody. It's Gavin Westmoreland here. I'm the Head of General Life Insurance at Barclays Corporate Bank and I'd like to welcome you all to the first in what we hope will be a long series of calls that we're running under the banner of Evolving Insurance.

 

Those of you who are already Barclays clients will hopefully have heard us talking for some time around evolving insurance. In summary, it's our customer-focused approach to banking the sector. We recognize that the sector is changing. The insurance industry is changing quickly and customer expectations are evolving and adapting. We, at Barclays, want to partner with you, our clients, to help you meet and exceed those expectations in order to drive your own businesses forward and to that end, we hope that you'll find these calls to be helpful in terms of giving you some topics of interest and development within the sector to think about and obviously we hope to be able to follow up with many of you on a one-on-one basis afterwards.

 

I'll hand over to Matt who can give you a little bit more of an introduction to the topic we'll be talking about today.

 

Matt: Thanks, Gavin. So my name is Matthew Paul and I work Business Payment Solutions and have been supporting the evolving insurance piece of work, as Gavin mentioned. Once again, we'd just like to thank everybody for dialing in today. Really appreciate your time and hopefully you'll find the session useful. I think one of the most exciting pieces or one of the most exciting things around the evolving insurance piece of work is the collaboration across the Barclays group and some of the unique assets that we have. And today, my colleague, Deanne Mott from Barclaycard Payment Solutions, will cover the work we're doing with a number of our merchants on payment acceptance optimization which is supported by issuing data that we see from our debit and credit issuing businesses which we -- which we believe kind of provides a really unique insight and is of really benefit to our merchants. So without further ado, I will hand over to Deanne.

 

Deanne: Good afternoon, everybody. Again, thank you for joining this session. So my name is Deanne Mott from the payment optimization team. I'm a consultant within that team and as part of my role, what we do is we look at how we can optimize acceptance rates for our customers. There will be a certain number of transactions that you process that will be declined.

 

A certain amount of those will be what we call "hard declines," so ones that you wouldn't want going through, but there are some that we would deem as "soft declines." So there might be something that we can do working with you individually to increase those acceptance rates for you. So the purpose of this session is just really to go through what we've looked at in terms of the insurance sector, how we feel we can support you going forward and what we can do with you on an individual basis.

 

So I guess initially what we do is we offer a consultancy service optimizing payments for you and we do that by leveraging our unique position as an acquirer, but also as a card issuer. So we work with our colleagues across the bank looking at our issuing data as well as our acquiring data to identify any areas where we can improve acceptance rates for you. We produce benchmarking reports which benchmarks you against your peers and also benchmarks us against other acquirers to see where we stand within the industry.

 

What we're there for is to enable businesses to maximize revenue, but minimize losses at the same time. What we don't want to do is to allow transactions through, but at the back-end you see an increase in charge-backs or fraud happening. So we want to make sure we're allowing the correct type of transactions to come through for your business.

 

Just at a high-level, industry insight shows us that there are a high volume of what we call ECI 7 transactions. That's non-secure e-commerce transactions and these are going to be impacted by PSD2 and strong customer authentication will also come in in September. (I know) Gavin alluded to a future webinar that will cover that for you.

 

What we're also seeing is around 15% of all declines for insurance companies potentially due to out-of-date card details held on file and there are areas there that we can help you with in terms of ensuring that card details are up-to-date before you attempt to authorize and debit those cards. And we see around 19% of all declines within the business are due to low funds.

 

So things that we can look at in terms of accepting or improving acceptance for you are things like the account updater service. That allows you to update card details before attempting authorization. The use of things like enhanced decline codes. So this gives you a wider transparency in terms of the type of declines you're seeing so that you can react in the appropriate way when you see those declines.

 

So if you see a decline that is for low funds, for example, you might try that later on in the day knowing that funds might be available later on or later on in the week. So it allows you to apply a certain amount of logic to how you retry those transactions going forward. And then also we can offer things like acquire exemptions for strong customer authentication and the impact that PSD2 might give you. So as I said, what we do is we do produce reporting. We look at benchmarking reporting and what we do with that is we look at you individually as an insurance company and benchmark you against all other insurance that we have and acquire for on our books.

 

This is just the industry report. So this just gives you an idea of the sort of things that we can do. As an industry, we see the average decline rate is 7.57% and we'll have some customers that are below that line and some customers that are above that line just purely by the way that they're processing transactions, the way in which they do them, the timings in which they process those transactions, etc and we can share that insight with you.

 

We look at declines at different parameters and do deep dives into those parameters and as I say, we do industry level analysis, so where you are against your peers at an industry level. So this graph just shows you different pricing points to (0.25, 25, 50) going up and what declines we're seeing at an industry level for each of those pricing points.

 

What we also look at is issuer analysis. So we look at the issuers that you are seeing as a business, identify issuers that have low acceptance rates and what we can do is deep dive into those issuers to understand why they might not accept as many transactions as some of the other issuers as an example.

 

So we have found that certain issuers, it might be just a profile of their customers that they are more likely to get low funds declines than other issuers as an example or it could be that some issuers don't allow transactions to be processed on an online basis or in a recurring transaction basis. So again, we can work with those issuers to understand the reasoning behind their declines and improve that for you.

 

What we can also do is look at the channels that we're seeing transactions coming in on. This is quite key for identifying any areas that are going to be impacted by PSD2 going forward or any areas where we believe traffic might move to. So the green line that you see there is the ECI 7s, or the non-secure transactions that we're seeing across the whole of the industry. That's showing the volume of transactions that we're seeing and the decline rate there which is the grey diamond that you can see on that graph sitting at 5.6%.

 

Now, that portion of traffic is going to be impacted post-September and we can work with our insurance customers to alleviate that impact. What we also anticipate is we will see that some people will move to mail order channel, particularly the fraudsters who want to use the channel of least resistance. So again, that's another area in which we're monitoring to see what the impact is post-September for our customers.

 

The box at the bottom (and the) yellow line, that shows the recurring transactions that we see within the industry. Those are the regular payments that we see across the insurance industry on a monthly basis where people are paying premiums and you can see there that the decline rate there does stick out as being higher than the other channels and I'll go into the reasoning behind that later on.

 

What we have looked at as well, particularly for the insurance sectors, we do know that you do batch authorizations. So where you're doing recurring and you debit customers on a monthly or weekly or yearly basis, that you might push all your authorizations through in a batch file at a certain time of the day. So we've done our own analysis across acquiring and issuing and across the bank in terms of looking at (fax) data for salaries coming in and things like that to identify the best time for acceptance rates if you're pushing a batch authorization file through.

 

And what we've identified is the key time for acceptance rates is around 10:30 in the morning. It's normally the end or the beginning of a month. Obviously that coincides when people are generally paid and the best day of the week is a Friday. So again, we've had some success with some of our insurance customers in moving the batch timings and then seeing an increase in acceptance rates just purely by moving that batch by a few hours. So again, that's something we can work with our customers on.

 

We also look at decline reason codes. So to split it down even further, see exactly what the reasons are behind the declines. The majority of declines do sit in what we call "do not honor" (pot). So various issuers who do put a lot of their transaction through as do not honor. That isn't transparent. There's no way of knowing the true reason behind that, but where issues do (flow) the different reasons, then we can identify those and share them with you.

 

You can see the second highest there is low funds and again, by moving things like the batch authorization file, you might find improvement in those sort of declines. There are other areas as well that you see, things like expired card, bad card number and transaction not allowed. They point to maybe card information being out of date. So either cards have expired between the times that the authorization has taken place or the cardholder has lost their card or changed their card number for some reason and you need to acquire the updated card details.

 

So again, there are areas where we can help you with that. As I spoke about before, things like the account updater service can provide updated information prior to you attempting authorization and therefore could alleviate some of those sort of decline codes.

 

We also look at retrys as well, so where transactions of sale, for example, CVV2 failures, we look at was that down to customer lethargy? I'm guilty of it myself. I don't take my card out of my wallet. I think I know my three digit number for my credit, but often get it mixed up with my debit card. So I fail on the first attempt, but on the second attempt, I'm successful.

 

So again, we can look at things like that to understand customer behaviour, understand whether it is the customer that is just making a genuine mistake or is it a potential fraudster that is trying several times to try and get that number right?

 

From a Barclays perspective, it tends to be fraud related or it's down to the way the card is set up. So things like CP remote purchase, that means that the card has been set up for card present only and therefore the decline is because this is a remote purchase or the card is not present. So again, we can try and identify and look into the reasons for those do not honour decline codes from our perspective.

 

We look at specific issuing data and what that allows us to do is actually benchmark us against our peers as an acquirer. So we benchmark ourselves against (the likes of Will Pay) or Lloyds TSB, HSBC to understand what we look like in terms of the industry. Thank you. Hopefully you're seeing that.

 

So again, what we're looking at here is the decline reason codes for each of the issuers that we see using Barclays debit cards, again, in the insurance sector. Each of the colored blocks represent a different decline reason code and you can see there are certain issuers that have higher declines.

 

So for example, hopefully you'll see there, Lloyds TSB, the third column in, you'll see that they have quite a high volume of insufficient funds in terms of declines compared to Barclaycard. But again, I'd want to caveat to say that that could be purely down to the type of insurance companies that Lloyds have on their books. It could be particular insurance companies that have high premiums and therefore lends itself more to having declines that are due to insufficient funds.

 

And what we can do is drill that down further, again, down to channel level. So where we did it from an acquirer lens view, we can do that from an issuer lens view. So again, the far right-hand column, so if you're looking at October, you can see from a recurring transaction perspective. So we look at the way the transaction's flagged from a recurring perspective. We see that acceptance rates are the lowest across all the channels and again, the top one there is insufficient funds, but there are areas that we can work with you on in terms of bettering those acceptance rates.

 

I'll just touch on this quickly. I know there's going to be another webinar in terms of PSD2, strong customer authentication, but from our team's perspective, we can draw on the data to identify where we can support you from a PSD2 and strong customer authentication perspective. So as an acquirer, we can provide exemptions up to €250 and what we can do is identify which transactions fall in the non-secure e-commerce bracket up to the €250 mark and where we could support you as an acquirer to flow low risk transactions via our own acquirer exemptions.

 

So that will lower the friction that your customers see. They won't have to authenticate themselves. You can route those transactions via us for under €250 and we can then route those out with an exemption flag attached to them.

 

We also look at secure e-commerce as well. So we're not just concentrating on non-secure. From a secure e-commerce perspective, we will still see further friction. So where you process transactions securely, there will be a large percentage of those that are actually passively authenticated at the moment.

 

When we say passively authenticated, none of those (are) stepped up. If you're a regular user of a particular website, you won't be asked for your password as a cardholder, but post-September, that will kick back in again. Cardholders will be asked for those passwords again. So there will be added friction through the secure channel as well and we can help with those.

 

This just gives you, as a say, the percentage of transactions that sit in each bracket and how we can support you with each of those.

 

We work closely with Admiral and we've got a case study that we can share. We will share this with you after the event, but there are some sort of, I think, key areas that I just want to draw out from it for you. So I guess in terms of being a client of Barclays, they've been a client with us for over 10 years and they wanted to review their corporate structure and payment ecosystems, looking at whether there are any areas in the customer journey where there were pain points? Did those pain points generate or impact the declines? Did those pain points cause additional cost within the business as well?

 

As well as just looking at payment optimization, we also look to where we could cut costs for the customer. So that could be cutting down the process that the call centre agent or the time that the call centre agent spends on the phone with a customer, sorting out issues through transactions not being authorized or identifying the best time to push through their batch authorization.

 

So we worked closely with them on that. We did deep dive analysis on our acquiring and or assuring data and introduced things like the account updater service so that all their details were up -- were up to date and as I said, change their batch processing time to minimize declines relating to insufficient funds.

 

I think they key part from that is that (obviously) Admiral saw (€)24 million in additional revenue. So when we talk about additional revenue, that is a combination of reduced costs, increased time that call centre agents can spend on higher value and premiums and increased premiums as well.

APIs and Open Banking

Open Banking is governed by the EU’s second Payment Services Directive (PSD2), and an Order passed by the Competition and Markets Authority (CMA) following its review of retail banking. Listen below to find out more.

Henry: Today we’re looking at Open Banking, and trying to demystify it. We’ve had a lot of inbound queries from our clients really just trying to find out some more information about what Open Banking is, and on this webinar, we’re looking to explore that and look at the opportunities it opens up for insurance companies in this digital age, and how they might use this new regulation that’s coming in. I think it’s also important to note what Open Banking isn’t, and so we’re going to try and clear up some of that as well.

 

To do that we’ve got Harcus Copper on the line. He’s been with Barclays just shy of 30 years now and 25 of those years have been in cash management, across many roles within the bank but now he’s actually responsible globally for Barclays for our Swift, host-to-host, API connectivity and information services – that covers our Corporate clients but also our Financial Institutions clients, which insurance is a part of. So without further ado, I’ll have over to Harcus.

 

Harcus: Thank you very much, Henry and good afternoon everybody, thank you for taking the time out of your very busy schedules to come and listen to this webcast today. If you do have any questions then do feel free to use the Q&A throughout, just start entering those and we’ll get to the Q&A at the end, and if at the end anybody wants to raise a question it will be *1 on your keypad, but we’ll go over that at the end.

 

So, into the meat of the content. We’re going to be talking about open banking, and what I’ll try to do as well, is I’ll try to bring that into context for the insurance sector.

 

So let’s just start by trying to position what open banking is. Now, at the heart of it, it came about through various requirements as a consequence of PSD2, and what the Competition Markets Authority did when following a review of retail banking, as part of the requirements under PSD2, to open up cash management capabilities to wider competition.

 

Broadly speaking, what open banking allows is for 3rd party providers, otherwise known as TPPs, to be able to access, on behalf of their clients, the type of functionality that the client (ie the account holder with the bank) would otherwise be able to access directly for themselves using the banks’ own channels. So, many of our customers obviously utilise our online channels, so largely speaking, what open banking requires of us banks is to ensure parity through the third party solution with what we would offer our customers directly through our channels. In the main, that boils down to the ability to view balances and transactions through the application and to initiate payments via those applications. Therefore, that comes under two titles: AIS (account information services) and PIS (payment initiation services) and those 3rd parties who intend to provide that capability must register with the FCA, and an entity known as the open banking implementation entity (the OBIE), in order to be regulated in providing those types of services. They are then known as account information service providers (AISPs) and payment initiation service providers (PISPs).

 

But obviously the term open banking in itself can cause various reactions as to what does that mean in terms of what those entities can do with the account holders’ account. The first thing to say is that it’s entirely governed through consent that’s provided by the account holder. So, the way that open banking is facilitated is through what we call APIs. Now many of you will be aware of what APIs are, so apologies for those of you who many already know this, but just so the whole audience has a broad understanding I’ll just briefly take a second to describe what an API is.

 

The acronym stands for application programme interface. In reality it’s a bit of code that allows two applications that otherwise wouldn’t be able to talk to each-other to be able to exchange information securely. A really good analogy, for example, which is why I use the pictures on the screen here, is the data provided by the met office when you want to look at the weather application on your phone to get an update of what the weathers likely to be today, tomorrow and over the coming week. Obviously the presentation layer on your phone is dictated by either the operating system, or the particular weather application that you’ve chosen to use, or a combination thereof, but the actual source of the data is always from the met office in the UK. Now, the met office, in essence, doesn’t speak phone and the phone doesn’t speak met office. So what the API does is it provides a bridge between the two. It provides a secure connection in a standardised format that allows that data to be exchanged and presented using the chosen operating system.

 

When you look at open banking, that entity I mentioned before, the OBIE, they were in essence created by a combination of market forces, ie: information from the banks, the Competition Markets Authority themselves, and various other players, to come up with a standardised way through which we banks can share data securely, and provide access to payment capabilities securely to 3rd party providers who wish to go on and become regulated as AISPs and PISPs in this context.

 

I like to think of open banking as two sides of the same coin, so what I’m going to try and do in this presentation is explain both of those elements.

 

The one side is where our account holders’ are facilitating access to their account through a 3rd party solution, rather than necessarily doing it through one of the channels that we banks provide. But, the flip side is that some of you as our clients may wish to take advantage of the open banking capabilities for yourselves, either by becoming AISPs or PISPs in your own right, or by utilising the service that we may be able to provide for you to do that, so that you can improve workflows to improve your own client base.

 

And for me, that’s the crux of what APIs and open banking is all about – it’s about improving workflows. If you look at what the market tends to talk about when it discusses open banking, it tends to concentrate on what is usually referred to as account aggregation. So, the ability to be able to view the balances and transactions of the accounts you hold with your multiple banking partners. But in reality in the corporate space that’s been available for many, many years through things like swift and host-to-host services, even our online channels can present not only our own accounts, but the accounts that we hold with other banks, only limited to that banks’ ability and desire to send swift messages for balance and transaction information, and respond to payment instructions in the form of MT101s if you understand and know those particular message types.

 

So, I don’t think, personally, that aggregation is perhaps, in the corporate market, the most exciting use case for open banking. It’s certainly a very, very valid use case in the retail space where that type of aggregation capability has not been available before. I tend to prefer to talk about it as an opportunity to improve customer workflow.

 

In this diagram I’m trying to, in essence, highlight that point by talking about the way in which customers utilise things like accountancy software, or treasury management applications. If you look at the workflow today, let me take for example Sage as perhaps an example accountancy software (and of course other software packages are available) and I know Sage are looking to become an AISP in this context, but I’ve not actually had this conversation with them, so I’m just using this to kind of, highlight the point. But if you think about what that accountancy software is trying to do in managing the customer’s books, the first thing it’s going to need is the balance and transaction information from the account, or accounts plural.

 

The workflow could look something like this today: I come in as the treasurer or financial controller for this particular business, and I open up Sage and the first thing it says to me is go and get the account information. So I come back out of Sage and I go to the bank’s online channel, Barclays.net in our case, and I find the master transaction reporting streams. Then I hit the export button, so I can export that data out in a particular format, then I save that export onto a folder somewhere, and then I come back out of Barclays.net, and I go back into Sage, and I find that folder and I find the file, and I use the import function within Sage, and eventually that data gets to where it needs to be for Sage to do its job.

 

Now obviously that’s not terribly cumbersome, that works very, very well. But imagine improving that workflow by simply putting a button within the Sage application that says “do you want me to go and get your bank data?” and then through the open banking rails the account holder can press that button, they simply select their account holding bank. And then what happens within the Sage app is that users’ online banking credentials within the bank the login screen is displayed within the Sage application, and then as the user, they simply enter their typical login credentials to the banks’ application to give consent to the bank of Sage to go and get that data for their account. And in the account information services flow, that consent is a 90 day consent. It means the user says “I can press this button once and then, within certain constraints, Sage can come and get that data every single day for me without me having to do anything further, other than in 90 days’ time I’ll have to grant my consent again.” So the workflow is massively improved, by simply going into the application that I wanted to use and using it to call for the data that it needs from the bank.

 

And equally then on the payment side, if they were to extend their capabilities to PISP (payment initiation service provider), then again if there was say an invoice I needed to pay, rather than record all the invoice details in that software, and then leave that application, and come into the online channel to make the payment, where I’m basically rekeying the data. I could press a button within the channel and again it calls for that consent, so again my online channel would appear within that application. I, as a user, then would simply enter my user credentials to consent to that payment instruction. But, unlike the AIS, that’s not a 90 day consent obviously, I would have to have to do that for every payment I wish to consent to.

 

Therein also lies a little bit of a limitation with online banking, is that consent is very good, very useful within account information services, you know, it’s for 90 days. In the payments space, equally it provides all the security and confidence you want to know that the application isn’t calling for payments it should not be doing, but it does rely on the banks’ channel as the credentials for which a user grants the consent. So, if you have a dual authority process then obviously the user within the 3rd party application gives the first consent, but the 2nd user would typically come entirely away from the 3rd party application, and log in to the bank channel where the payment is queued waiting for the 2nd authority before the bank starts to process it. But as I say, the intent therefore is to look at how open banking can improve the workflow from the customer’s point of view.

 

Let’s flip the coin over then, and think about it not from the context of the account holder simply utilising the services of the 3rd party, but what if you were the 3rd party?

 

For example, you might be in a claims situation as an insurance provider. And the workflow could be something like an online or telephone based claims process, at the end of which you need to obviously pay-out if that claim is upheld and you wish to give your customer a pay-out against that. The workflow in that context obviously is entirely reliant on payment exchanges, and I’m going to talk about that element a little bit later, through what I call the direct-to-corporate APIs, but what about the application process in the first place? Where, before I even get to the point where I’m talking about my own customer interface around payments out and things like that. What about a workflow that says my application process for the product I’m selling my client is entirely online, but at the end of that process the payment element may be a little bit clunky, you know, if it relied on the user coming away from your website entirely and making a push payment through their online channel. That comes with a very high dropout rate, it comes with a very low reconciliation rate, because you can’t necessarily rely on the user quoting the correct reference for the inbound payment team, and then your reconciliation becomes a problem. Equally, paying for things by card is absolutely fine, but again, that may be relatively expensive for you, and it may be relatively cumbersome for the user. So, through open banking you could perceive a process that means in that online workflow the user, the applicant, could simply consent to a payment being pulled directly from their account via a PISP.

 

Now there are certain limitations around what PISPs can do; one of those technically speaking is that you shouldn’t be paying yourself or using the system to call a payment to yourself, however if you had someone that was providing the PISP services to you, then obviously it would be your workflow powered by that provider. And Barclays is very much, in partnership with Barclaycard, looking at exactly that type of capability; where we would provide PISP services to add another alternative payment method alongside card payments, alongside push payments, where the user within your application process could simply press a button that says “yes, I’d like to pay for this directly from my current account please, and I give you consent to do that using the open banking rails” which in this context then would be powered by Barclays.

 

Equally you could see where, depending on the products and solutions you’re offering, the account information side of things could be beneficial, I mean if it was a lending product that’s a very good analogy, maybe not quite so relevant to this audience but just to bring the point home. If I had, as the provider, an online lending application workflow that at the end of which still relied on the applicant submitting to me 3 months’ worth of statement data, which is either going to be through the post in a paper statement or a PDF copy, instead I could perhaps build within that workflow an open banking consent layer that would allow the user to simply give consent to the lending company to call the data directly from their bank account so they can assess that application immediately and make an immediate confirmation as to whether or not they’re prepared to provide that loan.

 

So, lots of potential beneficial workflows where open banking may be able to provide capability. To recap before I move on, on the one hand open banking is very much around allowing 3rd party providers to access the same level of functionality that we banks provide our account holding customers, through our own online channels, and certainly you could utilise it in that context - as an account holder in your own right. Or, if you flip the coin over, you may consider becoming a 3rd party provider in this context, perhaps using a PISP solution provided by for example Barclays, in this case with a joint venture that we’re looking at with Barclaycard, to allow you to improve the workflow you have, particularly with your online solutions with your own client base around those applicants paying for the services you’re providing through that online solution. Or, by gathering information you need in relation to the user’s bank account, if you’re in that particular type of business.

 

I also mentioned pay-outs. The reason I did that deliberately was to remind me to talk about what we’re referring to as direct-to-corporate APIs. To recap, the API is simply a methodology by which one application can talk to another. Traditionally, in your day-to-day management of your business, and the way you manage your accounts with the bank, there have been basically two types of channel that you can do that from for many years. There are the online channels, so in our case that’s Barclays.net, and there are what are often referred to as unattended or integrated solutions, such as swift and host-to-host capability. So, by introducing the direct-to-corporate APIs we are introducing a 3rd type of channel capability that will allow you access to your own accounts. If you think about the type of functionality, as I say this boils down to very like much the open banking requirements of balancing transaction reporting and the ability to make payments. Whereas with open banking it’s about allowing a 3rd party to access someone’s account, with direct-to-corporate APIs it’s very much about allowing you to access your own account, in a slightly more efficient manner, or a manner that perhaps better suits your own desires for straight-through-processing and integration with your own back office systems.

 

If you look at online banking today, that has the beautiful advantage of most things in online banking are in near real time, but the disadvantage is that you have a user having to sit there pressing buttons to achieve the things you want to achieve through the online channel. Whereas if you flip that over to swift for corporate services or host-to-host capability, you completely take the user out of the equation, because you’re building a secure pipe between your back office system and ours. And through that pipe you would submit payments instructions to us, and we would return balance and transaction information, and payment status reports to you, and that would be fully automated straight-through-processing. But swift and host-to-host tend to lend themselves more to batch processing and end of day capability, not truly real-time in any way, shape or form. Whereas direct-to-corporate APIs can be seen as a very good hybrid between the two solutions: all the advantages of the near real-time capability of an online solution, without the disadvantage of a user, therefore all the advantages of a host-to-host, ie take the user out of the equation and fully integrated into your back office, without the need for batch processing, or end of day processing. So, certainly if you were doing a massive payroll file at the end of every month, probably the best solution for many years to come will continue to be the host-to-host type solution, where that file can be submitted as one big batch down the very secure pipe, and the bank processes that as a batch. Whereas the APIs lend themselves much more toward regular interfaces with smaller batches, frequent transactions.

 

The types of APIs we’re planning to build in 2019: one for getting my balance, one for getting my transactions, and those we would intend to be “parameterisable”, so if you chose, for example, to call the API to simply return all the credits received, or all of the debits above £100, or every BACs payment that’s received or sent, you would be able to select within those parameters what data you want to return. Our third one will be to make a faster payment, and that one absolutely is the priority for delivery this year, the others, the build phase will be the this year and the delivery may not be until early part of 2020. And then we do already have a proxy payment API, which has been live for a couple of years, but we’re going to move that into our strategic API environment so that will be upgraded in 2020 as well.

 

So the make a payment API, the first phase of that will be about making make a faster payment. You can call our API to make single, immediate faster payments, or small batches of payments. Let me try and bring that to life, and give an example that perhaps relates to my payroll, for example. In the gig economy, gig employees tend to not want to be paid weekly or monthly, they tend to want to be paid for either a task, or shift, or number of hours perhaps that they’ve worked, and that can even be daily. For example, I’m a gig employee, I might have with my employer some sort of application that records my activity be that a specific set of tasks, or a certain number of hours, or a day shift, and at the end of that activity I press a button and say “right pay me now” and your application would then validate that the employee has competed the work for which they are due to be paid, and then it would call our make a payment API to make a single, immediate payment to that intended beneficiary. So instead of having to wait until the end of the week, or the month, that gig employee type scenario begins to play out in a much more efficient fashion, and of course, multiple employees could be calling that API throughout the day and that’s absolutely fine – that’s what APIs are geared towards. As I say, the fundamental difference is APIs are about single, immediate or small batches, frequent transactions, typically of smaller value vs the host-to-host type solutions, which are much more about big batch processing, so that would be more like a payroll file.

 

As I say, we’re planning to deliver direct-to-corporate APIs, the make a payment API will in fact be a generic API, and it will cover any payment type. But for 2019 we will concentrate on the components of that API that will allow you to instruct single, immediate faster payments through our network.

 

As I said, the payment challenges, the type of capability that’s described here around gig employees is what I’ve just used as my example, they need a real time scalable disbursement system that allows them to make pay-outs on a daily basis. And in that context, it’s considered that typical ACH type payments are slow from a gig economy perspective, so what we do is, we still have to settle via the ACH, but the inefficiencies are resolved through the API, by the number of payments you’d be able to call frequently, rather than waiting to batch up transactions at the end of the day.

 

The way that our APIs will be exposed, this is also true of the open banking APIs, we keep them all in one place, that’s known as the Barclays Development Network or the Barclays API Exchange. In the open banking context, you would have to have an open banking license to be able to access those, and then we would grant you access to those specific APIs. In the direct-to-corporate API context, once those APIs are live, it would be a self-service solution where you would go to: www.developer.barclays.com where the APIs would be exposed to you. You can then test them; explore them in terms of what the opportunities are for you to interface with us via APIs could be; test them in a safe, sandbox-based environment; and then once you’re happy and you’ve completed your testing through an agreed process we’d then switch you to live, and you’d be able to integrate those APIs into your workflow. You can think of the direct-to-corporate APIs as solving multiple problems, the gig economy example I gave was just hopefully one which I hope help bought that to life.

 

That brings me to the end of the formal part of the presentation. I’ll just do a quick recap to say that open banking, as I described, is all about using the APIs written by the open banking implementation entity on behalf of the UK industry, to allow 3rd party providers to access your accounts. Or, should you chose to be the 3rd party provider, for you to be able to improve the workflow by allowing access to your own client’s accounts. Whereas the direct-to-corporate APIs are about you managing your own accounts in a traditional sense, but moving away from typical online or swift and host-to-host payment solutions to something that has all the advantages of direct integration, but the speed of a near real time service.

Strong Customer Authentication

SCA is a new European regulatory requirement to reduce fraud and make online payments more secure. To meet SCA requirements, you will need to build additional authentication into your checkout flow. 

Confirmation of Payee

Confirmation of Payee is a new name checking service for payments from PayUK going live on 31st of March. The service enables consumers, businesses and corporations to check the name of an account against the sort code and account number and provides an alert confirming or declining that the account details and account name match. 

Read related insights

Click on the links below to explore some of our recent, topical content, and pages that may interest you.

Insight

Insights from the Financial Institutions Group

In our latest update from the Financial Institutions Group, our industry experts are looking at the changing market, and how new technology and regulation is impacting the market at pace.

Insight

PSD2

The revised Payment Services Directive PSD2 came into effect in 2018, the implications of which have been wide reaching for both, banks and corporates alike.

Insight

Evolving Payments Landscape in Europe

This article takes a closer look at two recent regulatory updates that will impact the future of the European payments industry.
 

Industry expertise

Insurance

Get support and expertise from Barclays Corporate industry specialists across the insurance sector.

Contact us

Contact us

Get in touch

To discuss your business requirements and how Barclays can support you, contact us today.