00:04 Hello everyone and welcome to the World Bank's webinar series on fast payments.
00:08 My name is Colin Coulter,
00:10 and I'm a consultant with the World Bank based in Washington DC
00:14 Project Fast,
00:15 or frictionless Affordable Safe Timely Transactions,
00:18 is a flagship project of the World Bank sponsored by the Gates Foundation
00:22 and which aims to accelerate the adoption of
00:24 fast payments in low and middle income countries.
00:26 Now just a reminder that you can find all the resources that
00:29 the World Bank has been producing on the fast payment work,
00:32 including the recordings of these webinars under Project Fast.
00:36 On a dedicated website,
00:38 fastpayments.worldbank.org,
00:41 today we are continuing with our series this time
00:43 focusing on prominent overlay services and fast-paced payment systems,
00:48 and we really have the perfect guest to lead us through that conversation,
00:51 Claudio Cerrazani.
00:53 Claudio's career spans 25 plus years of extensive leadership,
00:57 management,
00:58 and global business experience in payment systems.
01:01 He is a subject matter expert
01:03 on real-time payments,
01:04 high value in retail payments processing,
01:06 central bank digital currencies,
01:08 and the clearing and settlement of securities and equities.
01:11 To date,
01:11 Cloudy has worked with more than 60 countries' payment system infrastructures,
01:16 providing business and technical advice.
01:18 He has also personally shaped the transformation
01:21 of more than 30 national payment system implementations.
01:24 In 2018,
01:25 Claudio launched DGT Solutions
01:28 designed to empower central banks,
01:29 financial institutions,
01:31 and FinTechs to undertake complex payment system transformation initiatives.
01:36 And since then,
01:37 the DGT Solutions team has supported payment
01:39 systems development in more than 20 countries.
01:42 Such as the UK,
01:43 UAE,
01:43 Saudi Arabia,
01:44 Montenegro,
01:45 Albania,
01:46 Kosovo,
01:47 North Macedonia,
01:48 Maldives,
01:48 Lesotho,
01:49 Tajikistan,
01:50 Gambia,
01:51 Vietnam,
01:52 Palestine,
01:52 etc.
01:53 The list goes on.
01:54 So we really have the perfect guest today to talk us through
01:58 prominent overlay services and fast payment systems.
02:01 Claudio,
02:01 thank you so much for joining,
02:03 and the floor is yours.
02:06 Thank you,
02:06 Colin.
02:07 Thank you everyone.
02:09 Today we will focus on overlay services,
02:14 so
02:16 overlay services
02:18 that actually are around what is the fast payment system.
02:24 What are overlay services?
02:26 They are,
02:27 of course,
02:27 value added features that are,
02:30 let's say,
02:31 layer on the FPS core infrastructure are
02:35 completing,
02:36 let's say the FPS core infrastructure.
02:38 We will say we will see how
02:41 and
02:42 what actually,
02:43 what is the scope of the various services is basically to
02:47 make an instant credit transfer.
02:50 And
02:51 cover use cases
02:53 that a normal push payment could not cover.
02:56 A normal push payment with
02:58 an account identification could not cover.
03:01 So
03:02 that actually is allowing
03:05 an FPS
03:06 to
03:07 expand its reach and
03:10 cover multiple use cases.
03:12 And of course what the benefit is that
03:15 of course it's promoting adoption
03:18 and
03:19 competition,
03:21 innovation because it actually creates
03:24 a layer of
03:26 business
03:27 functionality that can
03:29 be used to create a new service and
03:32 of course as a consequence of inclusion because it can reach.
03:35 Any kind of
03:38 a person,
03:39 any kind of business.
03:43 These are just a list of common overlay services.
03:46 Actually,
03:47 the list is increasing
03:49 and you can see
03:51 a request to pay,
03:52 confirmation of payee,
03:54 proxy directory
03:56 using a flies,
03:58 biller directory
04:00 that actually
04:02 integrating billing system with the fast payment system,
04:06 tokenization.
04:08 Let's say
04:10 changing the account number in random tokens in order to
04:15 for privacy
04:17 white label application
04:19 enabling the PSPs to use
04:23 a pre
04:26 adapted preformed white label application
04:29 for management,
04:30 the possibility to
04:32 For the FPS operator to
04:36 install a centralized management system and share
04:40 the service with the PSPs,
04:43 core code Man,
04:43 a centralized system that can issue
04:46 core codes.
04:47 Also the FPS,
04:49 I
04:49 think as we discussed in other webinars,
04:51 can also be
04:52 leveraged to
04:55 do an open banking app
04:57 now today.
04:59 We will just focus on the,
05:01 let's say,
05:01 what is the prominent of services
05:04 that are requested to pay
05:05 a confirmation of pay.
05:10 There are general capabilities that are common
05:14 to these two overlay services request to pay and confirmation of the
05:19 Messaging standards.
05:21 Currently ISO 2022,
05:23 it's dominant.
05:25 It's of course it's de facto standard.
05:29 Some of jurisdictions are still not using
05:32 ISO,
05:32 but it's more an historical reason.
05:36 And
05:38 let's say all the most recent
05:40 implementation and of course the future implementation
05:43 will adopt ISO 20022,
05:45 very flexible
05:46 and with specific messages
05:49 for requests to pay and confirmation of pay.
05:52 Operational hours,
05:53 these are the service of a fast payment system
05:56 and of course they must follow
05:59 the same
06:00 availability
06:02 standards,
06:03 so they must run 24/7.
06:06 API
06:07 more and more overlay services are based on API more than messaging.
06:16 So and we will see that
06:18 let's say that the trend in the market is that specifically for the services.
06:24 And
06:25 the use of API is becoming
06:29 predominant.
06:32 The use capability,
06:33 the possibility to use these
06:37 services using aliases,
06:39 so both a request to pay and confirmation of pay as the possibility to use
06:45 aliases instead
06:47 account identifications.
06:49 Access channels.
06:51 These services must be,
06:55 must be
06:56 available on all channels,
06:58 same as
07:00 fast payment system participation.
07:02 Now participation,
07:03 it's another.
07:06 Let's say specific um.
07:09 Uh,
07:10 of,
07:10 uh,
07:10 the,
07:11 the confirmation of PNR requests to pay that actually can have uh
07:15 It can be treated as a separate service to the first payment,
07:19 although they are complementing
07:22 the fast payment system and they are enabling fast payment system
07:27 use cases,
07:28 they can also be seen as a separate service,
07:30 so the participation
07:32 to this overlay service can also be
07:35 separated.
07:36 Let's say that participant to overlay service can be
07:41 more
07:42 or less than
07:43 the participant of the FPS.
07:46 Business continuity,
07:47 of course,
07:48 exactly this is because it's coupled with
07:52 a fast payment transaction.
07:54 You must
07:55 take care of the business continuity
07:57 with the same care
07:59 as the fast payment system.
08:05 Now,
08:05 first,
08:06 let's start with request to pay.
08:08 What is the goal of request to pay?
08:11 Streamline payments,
08:12 enhance flexibility,
08:13 improve cash flow,
08:14 and expand FPS adoption,
08:16 um.
08:18 Motivation are many and
08:20 let's say you can see it here in the slides,
08:23 but what I want to also to stress that
08:26 the request to pay
08:27 is
08:29 A really powerful tool.
08:32 Request to pay protocol.
08:34 It's
08:35 extremely flexible,
08:37 so it
08:39 can really be used
08:41 also beyond the use case that I will now show
08:45 because actually it's open to creativity from the PSP
08:50 also to create
08:51 new services.
08:54 These are let's say basic request to pay transaction flow.
08:59 There is of course
09:01 an engagement with the payer and the payee on
09:04 buying
09:05 goods,
09:05 services,
09:07 and point number 1
09:10 when agreed this exchange,
09:12 the payee
09:13 can send
09:15 a request to pay to the payer.
09:17 It's
09:18 sometimes also called the pool.
09:20 Payment.
09:21 So
09:22 the payee is pulling
09:24 the payment.
09:25 The payer
09:26 can offer accept,
09:28 reject,
09:29 and then we will see there are also other menu options
09:33 depending on the use case.
09:34 And let's say if you accept
09:37 now the
09:39 step 4,
09:40 there is the credit transfer that starts as a normal,
09:44 let's say credit transfer,
09:45 instant credit transfer.
09:49 Uh,
09:50 these are some capabilities that
09:55 should be taken into consideration where implementing a request to pay
10:02 now
10:03 uh
10:03 just in a
10:05 Let's say in terms of experience of implementation,
10:10 um,
10:12 not
10:13 the request to pay a different maturity and then of course
10:17 not to request to pay.
10:19 As all the capabilities that we can see here.
10:22 This is more
10:24 a suggestion for a way forward.
10:26 These are
10:27 also including sophisticated capabilities that are
10:30 enabling
10:32 a more sophisticated use case on request to pay.
10:35 Also,
10:35 request to pay can be very simple.
10:37 Anyway,
10:37 I just mentioned,
10:38 of course,
10:39 the messaging
10:40 as it was pretty much standard.
10:42 Pane 1314 is the ASU standard.
10:47 One thing that it's important in SLA management,
10:50 so the capability
10:51 to
10:53 be sure that the end to end transaction,
10:55 both the request to pay and the linked payment
10:58 are enforced,
11:01 are enforced by the system.
11:04 The idea is that the request to pay can support multiple instruments.
11:08 Another thing that it's we are speaking about first payment,
11:11 but the request to pay as a tool can be also seen as a separate service.
11:14 So
11:15 a request to pay
11:16 can also
11:18 trigger a payment that actually is not a fast payment.
11:23 So in some implementation,
11:24 the request to pay,
11:25 it's actually
11:26 A wider than the first payment itself.
11:30 So after request to pay,
11:32 it's not mandatory to send an instant payment,
11:35 but you can also
11:37 complete with different
11:39 instruments.
11:40 So
11:41 it can be connected or not.
11:44 Let's say for the
11:46 maximum flexibility it's better to keep it open.
11:50 And
11:52 the possibility to monitor the processing time in the different steps and legs
11:56 and
11:57 of course the possibility to use the same infrastructure
12:02 to handle
12:03 both the payment trail and the new financial message as also the.
12:09 A request to pay and confirmation of the app code,
12:13 so payment,
12:14 nonpayment messages,
12:15 sometimes financial,
12:15 nonfinancial messages.
12:18 Fraud,
12:18 we need to also
12:20 understand that the request to pay
12:22 needs also fraud prevention because it's a pool payment
12:26 and being a pool payment it's also open to let's say the same type
12:31 of fraud that
12:33 an instant credit transfer
12:35 may have.
12:36 So
12:37 important focus on
12:40 fraud prevention
12:42 and there are multiple ways.
12:45 Transaction limits,
12:46 and I think it's also to define
12:49 the possibility to define.
12:52 Also rules that are that are related to transaction limits,
12:57 how a request to pay can be used in different use cases,
13:01 what are,
13:02 what are the limits you can put depending on where the request to pay is used.
13:08 Retailer measure is different from a request to pay using business to business
13:13 or in a billing
13:15 situation.
13:16 Of course,
13:17 another thing that it's important is a granular message status manager,
13:21 so the possibility to
13:24 categorize the request to pay in pending paid,
13:27 not paid,
13:27 rejected to be able to actually
13:32 track the life cycle of requests to pay also
13:36 connected
13:37 to the related payments
13:40 there can be one or multiple.
13:46 And
13:47 these are some of the business capabilities that are important,
13:51 so the possibility to have a single request to pay,
13:53 a recurring request to pay,
13:55 also a bulk request to pay.
13:57 You can see that in
13:58 some government
14:00 or bill application,
14:02 having the possibility to have a bulk
14:04 request to pay can be important.
14:07 The possibility to have a flexible acceptance option.
14:10 So for the payer accept now or accept later.
14:16 Possi to have the flexible payment mode.
14:20 Pay now.
14:20 I can pay later.
14:22 I can make partial payments,
14:24 pay some of what was requested.
14:28 And so these are the business capabilities that are very,
14:32 very interesting if you implement a request to pay.
14:34 But if you get a cancellation,
14:35 the possibility also to cancel
14:38 a request to pay
14:39 in certain use cases when your
14:42 request to pay is used to agree,
14:44 let's say when a request to pay is used for a similar direct debit.
14:49 You need also to be able to cancel
14:53 this
14:54 agreement that was
14:56 taken with a request to pay,
14:58 and of course you can also use the request to pay for other
15:02 specific.
15:05 Meaning
15:06 you can have multiple requests to pay to agree between payer and payee.
15:10 You can use the request to pay to send reminders
15:14 of payment
15:16 also
15:17 to trigger
15:19 OTP or approval to give extra security.
15:25 I'm speaking about this,
15:26 but there are actually,
15:27 it's not actually theory.
15:30 They put in practice all these business capabilities.
15:33 Make the RTP much
15:35 very,
15:36 very powerful.
15:39 These are
15:41 some use cases as I told the use case that the request to pay can cover are many
15:48 here I'm just,
15:51 let's say
15:52 listing the basic ones
15:54 that is one of FTP
15:56 that it's actually
15:59 the pay and FTP you accept reject,
16:02 and
16:03 basically it's giving
16:06 Full
16:07 control to the payer,
16:08 uh,
16:09 very,
16:09 very transparent,
16:11 uh,
16:12 and
16:13 can be even real-time,
16:15 um.
16:17 It's,
16:18 it's an idea for adopt payments
16:21 or
16:22 govern to
16:24 payment govern to personal outreach,
16:27 and
16:28 it's actually
16:29 one of the basic use cases that
16:32 let's say that an RTP can cover.
16:35 Then we have the recurrent RTP that actually
16:38 probably is the most interesting use of it.
16:40 Utilities,
16:41 rent,
16:42 bills,
16:42 telecom billing subscription,
16:46 membership insurance,
16:47 it's very powerful.
16:50 It can of course
16:52 actually be a valid alternative to the direct debit.
16:56 Actually it's much more flexible than a direct debit,
16:59 and
17:00 it is also
17:03 can be also more transparent
17:05 for the for the payer.
17:08 So it can also enhance.
17:10 The way direct debit is done.
17:12 And create a lot of flavors,
17:15 let's say,
17:16 of
17:17 let's say direct debits.
17:19 Then there is the last that I want to mention point of interaction request to pay.
17:24 Why it's important,
17:25 it's because
17:27 a request to pay if used
17:29 on a POS
17:31 can
17:33 mimic
17:34 a typical card transaction.
17:37 Usually when I mean when you want to go on the merchant,
17:41 the most common way it's
17:43 the payer,
17:44 the merchant started the transaction,
17:46 so the payer exchanged,
17:48 insert the card,
17:49 exchange some data with NFC.
17:52 And the merchant starts the transaction.
17:56 Of course in a in a fast payment system that is a push payment,
18:02 you typically
18:04 the basic use case on the merchant side
18:08 is
18:08 actually the opposite.
18:10 The merchant show a core code,
18:11 I read the core code,
18:13 and I push a transaction.
18:15 Using the request to pay,
18:17 in reality,
18:18 unlock
18:20 more use case that can be done
18:23 with an instant payment,
18:24 instant payment system,
18:26 an instant credit transfer,
18:27 because
18:28 with the request to pay,
18:30 for example,
18:31 let's say that I have my,
18:33 now I'm making it simple,
18:34 but actually it's much more complex,
18:36 but
18:37 if I have a card with my account ID and I
18:41 tap on the POS.
18:44 the POS,
18:45 actually the merchant
18:47 start a request to pay.
18:49 That goes to my bank.
18:52 The bank
18:53 basically can
18:55 there are some,
18:56 let's say,
18:57 rules.
18:58 Consider that a pre-approved transaction
19:01 if you have the money in the account,
19:03 goes to the confirmation and the merchant,
19:06 of course,
19:07 gives
19:08 you the goods.
19:08 So that's actually
19:10 now speak just one of the cases,
19:12 but give the idea
19:14 on what request to pay can unlock
19:17 when used on a
19:20 on a point of interaction.
19:22 Uh,
19:23 Claudio,
19:23 this is,
19:24 I really appreciate the breakdown on the kind of specific use cases.
19:27 I don't want to slow us down,
19:27 but I'm curious because in earlier slides,
19:30 you're talking about the importance of how this
19:32 can help build trust in the payment system,
19:34 how the importance of like fraud protection stuff,
19:38 um,
19:38 of course,
19:39 wrapped up within
19:40 an overlay services program.
19:42 I'm curious,
19:43 back on that slide,
19:44 are any of these
19:45 use cases.
19:47 Do you think they are
19:49 maybe more promising in building trust when
19:51 people are first launching one of these systems
19:54 than any of the others?
19:55 I'm just thinking about
19:56 it,
19:57 it's fully open.
19:58 Everyone can kind of use this.
20:00 If you're building an FPS launching or launching an RTP system,
20:04 which of these is kind of the strongest way to build trust in users?
20:11 OK,
20:13 every,
20:13 every kind of services
20:16 must be
20:17 introduced with care
20:19 because
20:20 it gives you the potential to have new use case,
20:23 but it's also opens up
20:25 to new
20:26 threats.
20:28 And
20:29 request to pay you can
20:31 may understand if you,
20:33 for example,
20:33 if you allow everyone
20:35 to send a request to pay to everyone else
20:40 and you may be receiving
20:43 a request to pay
20:44 from you don't know
20:47 and
20:48 you need to
20:50 before introducing a request to pay,
20:52 you need to analyze the specific use case and put
20:56 Very specific rules
20:58 on it
20:59 in order to create the trust.
21:01 If I would like to,
21:02 let's say start creating trust,
21:04 I would
21:05 start with,
21:06 let's say more utilities,
21:08 more like
21:10 business to person,
21:12 where in reality,
21:13 of course it's more controlled because
21:17 you can control who is generating the request to pay.
21:20 And a lot and you actually give more
21:25 transparency and more data to the payer.
21:29 And
21:30 to check what he has to pay,
21:34 so I send you an invoice.
21:36 I send you a subscription.
21:37 I can see,
21:38 I can check
21:40 it's good that it's what I was expecting,
21:42 and I can pay immediately
21:44 actually in the same in the same transaction or later.
21:48 I mean it depends probably
21:51 a utilities bill,
21:52 it would be have a pay later
21:55 functionality,
21:55 you know,
21:56 I want to check and
21:57 I can pay.
21:58 And I can probably
22:00 sometime put a time.
22:01 I mean,
22:02 OK,
22:02 I agree I pay at this date.
22:05 The sophistication of request to pay and the flexibility,
22:08 it really
22:09 can be very,
22:10 very high and give you all these,
22:11 and I think that it's what a customer
22:14 will like most,
22:16 and you are in a safe situation,
22:19 then little by little
22:20 can expand on other use cases.
22:24 Thank
22:25 you.
22:25 That's very helpful.
22:25 It's almost like the,
22:26 the real value creation is that transparency
22:29 that then builds the trust,
22:31 choice.
22:33 Uh,
22:33 thank you.
22:33 I don't want to slow us down.
22:35 OK,
22:36 now some legal regulatory economic aspect
22:39 aspects on the legal and regulatory,
22:43 of course it's important to
22:46 specify when a request to pay is a binding obligation,
22:50 meaning when,
22:51 and that is of course it's done with
22:55 and enforced with
22:58 request to pay scheme rules
23:01 so very clear.
23:02 Um,
23:04 very,
23:05 very,
23:06 very clear definition of the obligation
23:09 of the participants in this overlay service.
23:14 Then of course also
23:17 Ensuring customer potential,
23:19 so a very clear dispute resolution mechanism,
23:22 very clear liabilities.
23:25 between the participant who is paying for if something goes wrong
23:29 and then and that this can also be
23:32 different
23:34 depending on the use case that you are implementing.
23:37 If the request to pay is implemented in a point of interaction,
23:40 you can have
23:42 different obligation,
23:43 different dispute resolution mechanisms than if you are
23:46 doing,
23:48 let's say,
23:48 a request to pay
23:50 for a utility bill.
23:53 In reality,
23:54 every use case
23:57 most probably would have
23:59 its own rules.
24:01 In request to pay,
24:03 you don't actually have
24:05 a request to pay
24:06 as a protocol and scheme rules of request to pay.
24:10 Actually,
24:10 request to pay,
24:11 it's very different
24:14 in the way it's used.
24:16 I mean if I use a use case
24:18 it can be a totally different
24:21 business process and obligation than in another use case that must be very,
24:25 very clear.
24:27 So
24:28 it can be integrated
24:30 in the
24:31 fast payment system rule.
24:33 It's usually suggested to be separate exactly for the reason I was just saying
24:38 because the
24:39 the RTP rule can be actually quite complicated
24:43 and quite different depending on use case to use case.
24:46 In terms of fee models,
24:47 actually
24:48 there are many,
24:49 many models,
24:51 but usually because the request to pay is triggering
24:55 a fast payment system,
24:57 a fast payment transaction,
24:58 sorry.
24:59 And
25:00 you usually,
25:02 let's say the approach is to make it
25:05 free or very low
25:08 in order to create
25:11 more adoption because actually it's
25:14 pulling more transaction
25:15 on an instant payment system
25:17 and again depending on the use case
25:20 on a P2P most probably
25:22 you should go for no no fee.
25:25 Of course in a business situation you may also let
25:30 the participant,
25:32 let's say be more free or
25:34 charge
25:35 a higher fee.
25:36 So that's also
25:38 another thing.
25:38 The fee model can vary.
25:40 On a specific use case where they request to pay is used.
25:46 Let's see the timing.
25:47 OK,
25:47 I don't want to
25:49 too much on the request to pay benefit the challenges,
25:52 uh,
25:52 I believe,
25:53 uh,
25:55 every
25:56 request to pay has a lot of benefits that I can,
25:59 I can
26:00 really highlight that.
26:02 But of course,
26:04 again,
26:05 this new service must be introduced with care
26:09 because depending on the use case,
26:10 depending on is implemented.
26:13 You may have issues of privacy.
26:16 You may issue of fraud.
26:19 Sometimes you have,
26:20 you can also confuse
26:23 the payer.
26:26 So the other thing for for business for PSP
26:32 can be complex
26:34 depending on how the protocol is created.
26:36 So you may have additional cost.
26:40 Liability can be different.
26:42 So also the business process that you need to put in place can be complicated.
26:48 You need a specific,
26:51 let's say,
26:52 a regulation or rules around it
26:55 that
26:56 must be followed.
26:59 And you need to
27:01 have clearer legal liability rules that again
27:05 when you think of instant payment system,
27:08 it's one rule when clarify that and the request to pay can be
27:12 actually multiple
27:14 depending on
27:15 how you use it.
27:20 I
27:21 mean here we just
27:23 put some kind of example of request to pay.
27:26 In reality,
27:27 despite
27:28 the
27:29 power of request to pay,
27:33 the user request to pay,
27:34 it's not so wide as it
27:37 should be in my opinion,
27:40 and I think it's because of
27:45 Let's say
27:46 some sometimes being having something very powerful makes it difficult to
27:52 let's say apply it to a specific case and
27:55 break down all the business process,
27:57 understand the
27:58 make the
28:00 consumer understand the value and the businesses.
28:04 Anyway,
28:05 let's say that the request to pay,
28:06 if you can see,
28:07 was launched in the most prominent
28:10 region and jurisdictions.
28:12 So it's something that it's
28:15 in my opinion,
28:15 a key for a fast payment system to evolve.
28:23 These are some of the cross-cutting
28:25 success factors.
28:27 Regulatory push sometimes is very,
28:29 very,
28:30 let's say
28:31 good
28:33 because of course it's
28:35 pushing the market to adopt it.
28:39 The readiness,
28:40 it's of course important as I told the request to pay
28:44 can be a little bit more complicated to
28:46 be implemented than an instant credit transfer.
28:51 So that the fact that the bank and PSB are ready,
28:54 it's actually a key factor.
28:56 Standardization interoperability.
29:00 business case for merchant,
29:02 I believe that it's another key.
29:05 We need
29:05 to make the business case
29:08 very clear
29:09 to the merchant,
29:12 specifically in the pool
29:14 situation,
29:15 the payee
29:17 actually is driving that option.
29:20 So it's very important that it's clear
29:23 for the pay the
29:24 value of the request to pay.
29:26 Of course the fee model as for everything is influencing
29:30 and the trust and user experience for the for the consumer.
29:37 These are some lesson learned
29:41 trust
29:42 for specifically for the user
29:45 and also the
29:46 simplicity in some way to use it.
29:49 It's important for the user to
29:54 let's say trust this new actually
29:58 method.
29:59 Interoperability,
30:01 it's important.
30:02 I would not say that it's the most important thing because now
30:05 ISO 2022,
30:07 so
30:08 the interoperability is quite embedded in the use of it.
30:13 Regulatory clarity is fundamental,
30:15 so
30:16 that is actually,
30:17 it's one of the pillars of
30:20 making the system
30:22 be trusted by the users.
30:26 Merchant led rollout,
30:27 I already mentioned it.
30:29 The
30:31 payee
30:32 side,
30:32 it's actually
30:35 defining the success and the adoption of the request to pay
30:39 and then of course the adoption of the instant payments.
30:43 The request to pay
30:44 cannot be launched
30:46 like
30:47 in one shot
30:48 also because the request to pay is related to specific use case.
30:53 So
30:54 it can be introduced
30:56 in phases.
30:57 Actually it's a master
31:00 for the reason that every use case is different and may require different rules,
31:04 may require different integration.
31:06 So step by step starting for the most interesting use case
31:11 we are mentioning
31:13 before
31:14 utilities bills so that it's actually
31:18 probably the most common
31:20 starting point
31:22 and then of course enlarge and then also lead the market to
31:27 suggest how
31:28 request to pay can help
31:29 to create a new.
31:31 A new services,
31:33 innovative services,
31:35 it must be aligned with the national payment system strategy.
31:38 And time to market,
31:41 meaning you need to balance what the
31:43 sophistication you want to introduce and how long
31:47 you want to take to introduce in the market.
31:50 Sometime as a request to pay can be very,
31:53 very sophisticated,
31:54 but the last thing you want,
31:56 and you take 2 years to implement
31:59 use case.
32:00 So
32:01 even in a specific use case,
32:04 the single use case can be.
32:06 Let's say splitting steps,
32:09 so using
32:10 maybe
32:11 basic functionality for a specific use case and then evolve
32:14 over time.
32:19 Lesson learned last,
32:20 I think I just want to mention structured data
32:24 that they say hidden value.
32:27 What is important is that the ISO message can carry
32:32 remittance detail.
32:34 So
32:35 actually
32:37 the request to pay can carry a lot of data
32:40 inside
32:41 also depending on the implementation of the system,
32:43 but I mean.
32:45 Theoretically can include a lot of data that can of course streamline
32:50 the business processes,
32:51 so link the back office processes to the payments
32:55 to the payment leg.
32:57 So that's an automate
32:59 give at least the possibility to automate end to end
33:02 the process from the
33:04 let's say,
33:05 generation of the bill
33:07 to the payment.
33:09 Execution.
33:14 Now I will switch to confirmation of pay.
33:17 Confirmation in reality is a totally different,
33:21 is a totally different focus.
33:23 It was actually introduced
33:26 to
33:26 mitigate fraud.
33:28 Uh
33:30 That's actually,
33:32 uh,
33:32 that of course,
33:34 uh,
33:34 came in when uh instant payment system was introduced.
33:38 Reducing misdirected and erroneous payment.
33:40 Instant payment,
33:41 as you know,
33:41 it's a good thing that the funds are immediately
33:45 available to the payee
33:48 and debited to the payer.
33:50 But if I made a mistake,
33:51 there is no way back,
33:54 so.
33:55 The confirmation of payee
33:58 also
33:59 was focusing on reducing erroneous payment.
34:03 As a consequence,
34:05 they were both
34:07 these two objectives
34:10 to build trust because
34:12 of course
34:13 instant payment system
34:14 account to account payments
34:17 were introduced and of course the customers say,
34:19 OK,
34:19 instant payments is fantastic,
34:22 but
34:24 it's
34:25 it's a
34:27 it's open up of more fraud.
34:31 And
34:33 if I make an error,
34:35 it's difficult to have the money back.
34:37 So it was like these
34:41 trust issues from the users using the instant payment system.
34:45 The other thing is to improve KYC and email compliance and then we see,
34:49 because
34:50 of course the
34:52 confirmation of payee giver
34:54 can give the
34:55 certainty of who the payee is.
34:59 Also can be used to have a
35:01 more accurate KYCNML.
35:04 Compliance checks,
35:05 but
35:06 on this I will also open up a a new trend that is
35:11 that is coming on this.
35:13 This is very simple.
35:14 It is again,
35:16 we have an agreement within a payment per year on an exchange.
35:23 Then
35:24 they basically
35:26 starts before the payment
35:29 starts at a confirmation of payee request.
35:33 That is going from the pay participant to pay participant,
35:35 and the pay participant
35:37 will send back
35:40 now can be
35:42 a match,
35:43 no match,
35:43 meaning I can tell you if the
35:46 the name that you are using.
35:50 It's actually
35:51 matching,
35:52 partially matching or is no matching on actually the real name
35:56 associated to that account.
35:59 Now the payer
36:01 is presented to
36:03 more information about
36:06 the
36:07 payee.
36:08 So
36:10 I can see,
36:11 oh listen,
36:12 the name that you
36:14 you that you have
36:15 inserted actually is not the name
36:18 that is associated to the bank account.
36:20 Please check.
36:22 Uh,
36:23 maybe you make some mistakes
36:25 or maybe it's a fraud.
36:27 I means someone asks you to pay,
36:30 um,
36:31 and impersonating someone else that,
36:32 that's actually the.
36:34 There are many ways to do a confirmation of payee.
36:38 These I explained the same because
36:40 in some
36:41 jurisdictions the payee also can send back
36:45 the full name instead of saying match no match,
36:48 can send the full name
36:50 and the payer participant show the masked
36:53 name to the payer
36:55 again to support the decision.
36:57 At the end of the day,
36:58 in most jurisdictions,
36:59 the payer is in any case.
37:01 Free to start the credit transfer.
37:05 So at the end of the day,
37:06 the confirmation of pay is giving the payer
37:11 more information
37:12 to help me decide.
37:16 If you want to send this credit transfer,
37:18 the responsibility
37:20 is still on him.
37:23 to do because it's not preventing him to do it.
37:27 So that's I think also
37:29 important thing.
37:33 Core technical capabilities.
37:35 I don't want to go on all of that.
37:38 I mean I can mention a flexible transaction limit.
37:42 Maybe confirmation
37:44 of payee can be mandatory
37:46 for
37:48 above a certain threshold that can be not mandatory for small payments,
37:52 for example.
37:53 This also
37:55 actually depends on the use case.
37:57 Uh,
37:58 that you have
38:00 a confirmation of pay protocol probably um
38:04 it
38:04 it doesn't really work if you're doing a payment on a,
38:08 on a
38:08 point of sale,
38:09 let's say that.
38:11 So,
38:11 um,
38:13 let's,
38:14 depends
38:15 on also on the use case,
38:17 uh,
38:18 but it's important to that confirmation of payee can be also selective.
38:24 It's important to also to
38:27 monitor then to end
38:31 to end processing time because
38:34 now
38:36 when you do
38:37 an instant payment you also have the confirmation of pay before then.
38:41 So in the user experience from when you start the transaction to the end,
38:45 you also need the confirmation of payee to be immediate
38:50 because it influences the user experience.
38:53 And again,
38:54 of course
38:55 it's becoming
38:57 specifically where
38:58 in the jurisdiction where it's mandatory.
39:01 It of course must be available,
39:06 must have the same
39:08 requirements in terms of business continuing cybersecurity that
39:12 of the Islam Credit Council.
39:16 Models.
39:16 There are different models centralized,
39:18 decentralized hybrid centralized means that actually
39:22 everything is in a directory,
39:24 usually it's coupled with the alias directory.
39:27 That means that alias directory is also names.
39:31 So
39:32 when I ask a confirmation opinion in reality,
39:34 I am asking.
39:36 Let's say proxy resolution in terms of ISO messages,
39:38 the message is the same proxy resolution of it's called
39:42 identification identification verification
39:45 decentralized.
39:46 It's
39:48 basically.
39:49 The payer PSP sent to the payee PSP.
39:52 The message is the payee PSP that
39:54 sends back the result
39:56 of the confirmation of payee.
39:58 The hybrid that actually is not very common
40:02 where
40:03 depending on the capability of the payee PSP.
40:07 You can have both.
40:09 So
40:10 for some PSP,
40:12 it can be decentralized for pay PSP instead they can opt
40:18 not to receive the message but to opt to be to have the data in the central directory.
40:26 Some business capabilities and
40:29 of course
40:30 the possibility to manage a multiple identifier,
40:33 account proxy
40:35 LEI
40:38 response flexibility.
40:40 So
40:41 in order to have
40:42 a
40:43 rich feedback
40:44 option
40:45 here we are speaking about of course
40:48 business capability
40:51 when you can implement confirmation of payee.
40:55 This is of course
40:57 that is intrinsically was created for fraud mitigation.
41:02 And also the possibility to be cross border.
41:04 More and more confirmation of pay is
41:08 becoming a standard.
41:10 Um,
41:12 I don't want to enter.
41:14 I actually confirmation of payee in most of the use cases,
41:16 it's very important,
41:18 as I was saying.
41:19 Confirmation of payee
41:20 is starting to become
41:22 mandatory in many jurisdictions,
41:25 so you cannot do actually an instant credit transfer if there is no
41:30 confirmation of payee done
41:32 before then.
41:35 Maybe I will,
41:37 let's say mention TTR because I'm not sure if I
41:39 will be able to mention that it's a new trend.
41:42 It's
41:44 specifically when it's mandatory,
41:46 and I'm speaking
41:47 locally at also cross border
41:50 when there is some interlinking that
41:52 the confirmation of pay.
41:54 The AML and QYC checks and safety checks specifically
42:00 can be done actually at the confirmation of pay level.
42:05 So while currently
42:08 the AML checks are done
42:11 at the transaction of the payment transaction
42:13 level.
42:15 Now
42:16 if
42:17 that protocol is becoming mandatory,
42:19 you can actually move the EMH checks
42:23 at that level.
42:24 What is the advantage
42:25 that actually
42:27 you do the EML checks before starting a payment?
42:31 So if there is an issue,
42:33 you can actually
42:36 stop the transaction before
42:39 the payment,
42:39 specifically in an instant
42:41 payment.
42:42 Applying real-time AML checks.
42:46 And fraud managers check specific,
42:48 it's
42:49 a little bit more difficult
42:52 because you don't,
42:53 you have seconds to decide
42:55 if you
42:57 reject or accept the transaction
42:59 and specifically where you have
43:02 EML in EML you may have.
43:08 Let's say higher rejection rates.
43:11 So that's actually a trend that I see coming
43:15 and that's actually very interesting because the possibility to
43:18 do checks before starting a transaction where
43:23 it's much more difficult to manage
43:25 a possible AML
43:28 issue.
43:30 A
43:31 legal and economic framework,
43:34 of course it's required rule on data data occurs because actually it's all about
43:39 the accuracy of the data of the
43:41 of the users
43:44 oversight of PSP compliance and SLA that is actually important.
43:48 Privacy here we are speaking about the
43:52 the data of the of the users.
43:55 You must have a clear liability of
43:59 meaning,
44:00 as I was telling,
44:01 if
44:02 everything is done
44:03 correctly,
44:03 the liability stays on the payer side,
44:06 but if the error is created by the payee
44:10 participant,
44:12 then the liability shifts.
44:14 So if I say
44:17 a match,
44:18 but it was a false match,
44:19 now the liability is shifting,
44:21 so that
44:22 must be all true.
44:23 Now clear
44:25 economy economy.
44:26 Confirmation of peace,
44:28 it should be free because actually specifically when it's mandatory.
44:34 Because it is part of the transaction.
44:37 It's part of the instant credit transaction,
44:39 so
44:41 it's actually not logic to be to be challenged,
44:45 but specifically.
44:47 It's giving value actually.
44:49 It's in some way
44:50 making the system
44:52 save money
44:54 of all the issues that are related because it's actually reducing a lot of fraud,
44:59 a lot of erroneous payments,
45:01 so a lot of issues.
45:02 So actually it's
45:05 a value
45:09 we should see it's not a cost saving
45:11 than
45:13 let's say a service to make more fees.
45:18 These are some of the
45:20 experience that we listed.
45:23 I will let you go through them.
45:25 I don't want to
45:26 get
45:26 too long.
45:28 Benefits,
45:28 I think.
45:30 That the benefits are very clear.
45:33 I mean for direct experience here in Europe,
45:36 I think it's very nice to see
45:40 when you do a credit transfer you have a green logo
45:44 that you are sending to the right person.
45:45 There is no
45:47 and actually
45:48 for me personally it's really
45:51 a relief.
45:52 I mean you actually do a credit transfer much
45:56 more relaxed
45:58 and
46:00 And of course I would want to maybe to focus
46:03 more on the challenges
46:05 because there may be data privacy concern
46:09 specifically may
46:11 think,
46:11 but in reality
46:13 the way most of the place it's used actually
46:18 these data are not actually flowing through the confirmation of payee
46:24 and let's say that in any case.
46:26 And there are very strong scheme rules that are
46:30 covering the entire
46:32 first payment system.
46:34 For the business maybe integration costs even if in my opinion
46:38 the protocol is very,
46:39 very simple.
46:41 So yes,
46:41 there will be additional,
46:43 but differently for request to pay
46:46 where I'd say the integration could be complex.
46:48 Yes,
46:48 there are additional integration costs,
46:51 not very complicated.
46:53 Infrastructure complexity for the PSP,
46:55 I believe it's more than for the PC is adding these extra steps
47:01 and
47:02 Creating the flow for the customer
47:05 that
47:07 in real time is giving him
47:10 the result of the check.
47:12 So
47:13 yeah,
47:13 there is a little bit more complex and more resource
47:16 utilization because now for every credit transfer you have additional messages
47:22 and of course also there is additional logic.
47:26 to be implemented
47:28 liability for the regulators it is important to
47:32 understand
47:33 this liability in some cases what is happening if something goes wrong.
47:38 Sometimes,
47:39 most of the time,
47:40 let's say baseline liability is on the payer side,
47:44 but in some,
47:45 in some,
47:46 some,
47:46 let's say cases
47:48 this liability can be shifted
47:51 to the pay side.
47:55 Uh,
47:57 I see a lesson learned.
47:59 I think that,
48:00 uh,
48:00 I just want to summarize,
48:03 uh,
48:05 confirmation of P is really
48:07 adding a lot of value
48:10 on,
48:10 uh,
48:11 on domestic credit transfer.
48:14 Um,
48:16 let's say,
48:16 really,
48:18 let's say adding trust or giving more trust to the consumer and reducing
48:22 the error.
48:23 But I want to say in the cross border
48:27 it's even
48:28 more important.
48:29 The error and the complication in case of
48:33 a misdirected
48:36 payment in the cross border,
48:38 it's actually huge.
48:40 The cost to fixing
48:43 errors in a
48:45 cross border
48:47 are very high.
48:49 So actually the confirmation of pay
48:52 applied to cross border payment,
48:54 it's even more available
48:56 than applied to domestic
48:58 uh payment
49:00 so that that's I think uh.
49:03 And the other thing that I believe that
49:07 more and more
49:10 confirmation is going to become mandatory.
49:12 The value is so high
49:15 for the consumer,
49:16 the business in both domessenko's border.
49:20 That is going to become mandatory I believe in
49:24 most of jurisdictions they already have it let's say potentially
49:28 and the jurisdiction that they didn't implement it because
49:31 we also need to remember confirmation it's quite a recent
49:35 uh functionality
49:37 they are going to implement it.
49:43 Let's see.
49:44 The other is important,
49:45 and I want to
49:47 add that
49:49 of course ideally the confirmation of fee should be
49:54 using the same infrastructure
49:56 of the first payment system,
50:00 same request to pay more the confirmation of
50:01 fee because it's tightly integrated to the payment
50:05 confirmation piece is to use the same rail.
50:08 The same infrastructure of the first payment system,
50:11 although actually can be
50:13 separate.
50:14 It's not mandatory at all.
50:20 What is the
50:22 what are the policy implications
50:25 for related to the confirmation of payment request to pay?
50:28 The role of the central bank is that
50:31 they can actually operate an overlay service
50:33 to ensure that there is
50:35 a neutral
50:37 service
50:38 given to the to the PSP.
50:41 Uh,
50:42 increased complexity for the central bank,
50:44 but of course
50:45 I think it aligns with the public interest,
50:48 mandates the central bank has or
50:50 the payment system operator.
50:53 Motivation it's
50:55 clarity and liability rules,
50:56 interoperability,
50:58 so they can make these interoperable along
51:01 many rails,
51:03 more sustainable economics,
51:05 the possibility to have a minimum viable product approach,
51:10 MVP approach,
51:12 and of course the possibility to have a strong adoption,
51:16 stronger adoption and education strategies.
51:20 I think that the request to pay and confirmation of pay
51:24 are becoming an integral part of a fast payment system implementation.
51:29 I don't think that nowadays someone can imagine
51:33 to implement and introduce an instant credit
51:37 transfer system and an instant
51:39 payment system without
51:41 already
51:42 thinking
51:44 on how to
51:45 implement a request to pay a confirmation of pay.
51:48 This service,
51:49 of course.
51:50 They don't necessarily need to be
51:53 included
51:55 in the fast payment system.
51:56 Platform can be separated.
51:58 It can be.
51:58 There are service providers
52:00 that are giving requests to pay conventional pay service.
52:04 That of course that gives service to the community so it can be
52:08 separable.
52:09 What I mean is
52:11 And in the fast payment system implementation.
52:14 This must be an integral part of the strategy.
52:19 In any way,
52:22 the operator of Centralum wants to
52:24 implement it,
52:25 they must be in the strategy
52:28 and in the timeline in the project from day one because they heavily influence
52:34 the,
52:36 let's say,
52:37 the user of the Easter
52:39 payment system.
52:46 Excellent.
52:46 Thank you so much.
52:47 That was a terrific breakdown
52:49 of two,
52:50 you know,
52:51 essentially essential
52:52 uh overlay,
52:53 overlay uh products.
52:56 Um,
52:56 as a quick reminder to the audience,
52:58 all of this information,
52:59 as well as the recordings of
53:00 these webinars are available on fastpayments.worldbank.org.
53:04 Uh,
53:04 we also have another upcoming webinar and dispute resolution
53:07 mechanisms.
53:08 So thank you everyone for joining and have a wonderful day and thank you,
53:12 Claudio,
53:12 for taking the time to share,
53:14 uh,
53:14 this very important information.
53:17 Thank you.
53:18 Thanks everyone.
53:19 You have a good day.
53:20 Take care.
53:21 Thank you.
- add-style
- lp-body-content
Also known as instant or real-time payments, fast payments are characterized by the instant transmission of the payment message and by the immediate availability of funds to the beneficiary on a 24/7/365 basis. But authorizing, clearing, and settling a payment are but one layer of a robust fast payment system. Atop them lies a variety of overlay services that can improve product value, prevent fraud, broaden adoption, and drive the overall success of the fast payment system.
In this webinar, Colin Colter (Payments Consultant, World Bank) and Claudio Ceresani (Senior Payments Consultant, World Bank) discuss the role of overlay services (in particular request-to-pay and confirmation of payee) in fast payment systems, how they help build trust and adoption of an FPS, and how to operationalize them at the system level.