col-xs-12
col-sm-12
col-md-12
col-lg-12
col-xs-12
col-sm-12
col-md-12
col-lg-12
videoType
dynamic-media
videoDmUrl
https://delivery-p136806-e1377785.adobeaemcloud.com/adobe/assets/urn:aaid:aem:8c9ff64b-c205-4818-a062-5ccecab84aa4/play?assetname=Dispute-Resolution-Webinar-Jose-Antonio-20260128-180403.mp4
keyFrameImage
videoDescription
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 what happens when something goes wrong? Who is responsible when a payment is made in error, and how is that responsibility scaled across an entire jurisdiction of payments activity?
timestamp

00:02 My name is Colin Coulter,

00:03 and I am a consultant for the World Bank's Project FAST.

00:06 FAST,

00:07 or frictionless Affordable,

00:08 Safe,

00:08 Timely Transactions,

00:10 is a flagship project of the World Bank

00:12 and focuses on accelerating the adoption of fast payment systems

00:16 in low and moderate income countries.

00:18 Generously supported by the Gates Foundation,

00:21 Project Fast works to expand knowledge,

00:23 build capacity in key institutions,

00:25 raise awareness,

00:27 coordinate global stakeholders,

00:28 and provide technical assistance for the adoption of fast payment systems

00:32 around the world.

00:33 As a reminder,

00:35 all of the work of Project Fast,

00:36 as well as the recording of this webinar,

00:38 can be found on a dedicated website,

00:41 fastpayments.worldbank.org.

00:44 Today

00:45 we are continuing our webinar series this time

00:48 focusing on the role of dispute resolution mechanisms

00:50 in fast payment systems,

00:52 and we really have the perfect guest

00:54 to lead us through that conversation,

00:56 Jose Antonio Garcia Garcia Luna.

00:59 Jose Antonio is currently a senior payments

01:00 advisor for the payment systems development group,

01:03 the World Bank.

01:04 He's mostly involved in assisting countries in

01:06 the implementation of fast payment systems.

01:08 In assessing payment and other settlement systems

01:10 on the basis of the CPMI IOSCO PFMIs

01:13 and in financial inclusion initiatives like the World Bank Group CPMI,

01:17 uh,

01:18 work on payments aspects of financial inclusion.

01:21 He's also been involved in the production

01:23 of international standards and best practices.

01:26 Most recent country engagements include Albania,

01:29 Chile,

01:29 Colombia,

01:30 Dominican Republic,

01:31 Indonesia,

01:32 Paraguay,

01:33 South

01:33 South Africa,

01:34 Uruguay,

01:35 and Vietnam.

01:36 Antonio has held senior positions across finance,

01:40 education,

01:40 payments,

01:41 investment,

01:41 and credit.

01:43 He's led the program program on financial literacy at the Universidad Ahuac

01:47 in Mexico City,

01:48 and he has served as deputy CEO

01:50 of Infonico,

01:51 a state-owned financial institution based in Mexico City

01:55 that provides consumer loans to low-income workers.

01:58 Mr.

01:58 Garcia has also been a senior payment system specialist at the World Bank,

02:03 a senior economist at the Center for Latin American Monetary Studies,

02:06 and

02:07 a credit analysis specialist Abanco and Bursa,

02:10 both in Mexico City.

02:11 And so we really have the absolute perfect guest

02:14 with us today,

02:15 uh,

02:16 to walk us through that conversation.

02:17 And so with that,

02:18 Jose Antonio,

02:19 I hand the floor to you.

02:22 Thank you so much,

02:23 Colin.

02:24 It's really a pleasure

02:25 to participate in this new webinar.

02:27 Uh,

02:28 today,

02:28 we have a very,

02:29 very interesting topic.

02:30 It's about,

02:31 uh,

02:32 solving,

02:33 trying to solve in a in a balanced manner disputes that may arise

02:37 as a result of payment activity,

02:39 in particular,

02:40 fast payments.

02:41 Uh,

02:42 let me

02:43 share my screen

02:45 so that we can begin.

02:49 OK.

02:52 OK.

03:01 OK.

03:03 Here we go.

03:05 So,

03:06 let's start.

03:07 Uh,

03:08 when we are talking about a dispute,

03:10 what are we referring to

03:12 for the specific context of

03:14 payments?

03:15 Well,

03:16 we're going to adopt this definition.

03:18 Disputes

03:19 refer to

03:20 payments that have been executed,

03:23 but that are contested by any

03:25 of the parties involved.

03:28 And disputes may also refer to

03:31 other payment activities that are

03:33 contested.

03:34 For example,

03:35 uh,

03:37 a payment that actually was not created

03:40 to a beneficiary,

03:41 I mean the payment was probably not executed and there

03:43 might be a dispute on why it was not executed

03:46 as expected by

03:48 the payer.

03:49 Uh,

03:50 in disputes,

03:51 as you can imagine,

03:52 we have,

03:53 uh,

03:53 at least 2 parties involved

03:56 and

03:57 we're gonna

03:58 divide them into two broad categories.

04:01 The first one for the purposes of this uh webinar,

04:04 uh,

04:04 are those,

04:06 and the first category involves end users.

04:10 Uh,

04:11 end users that are involved in a dispute,

04:13 it could be,

04:14 for example,

04:15 a payer

04:16 versus

04:17 its payment service provider

04:19 or

04:19 a payer versus a payee

04:22 or the payee versus its

04:24 PSP payments service provider.

04:26 And the second broad category

04:29 is

04:30 the one that refers to disputes

04:32 that

04:33 have to do with differences between payment entities.

04:37 Payment system operators and so on.

04:39 This means that there is a dispute between one PSP and another PSP

04:44 or a PSP versus the payment system operator or PSO.

04:49 So,

04:49 these are the two broad categories.

04:51 However,

04:51 for the purpose of this

04:53 webinar,

04:54 we are going to focus

04:55 mainly on disputes that involve

04:58 end users.

05:00 In this area,

05:02 We have some international standards already in place.

05:05 These are the OECD G20 financial consumer protection principles.

05:11 These

05:12 standards call for accessible,

05:13 fair,

05:14 efficient consumer campaign handling.

05:16 And importantly,

05:18 these are intended to apply to any type of financial services.

05:22 I mean,

05:23 these were,

05:23 these were not created specifically for payments,

05:26 but they do

05:27 include

05:28 payments.

05:30 Uh,

05:31 then for disputes that involve end users,

05:33 what is the typical flow here,

05:35 I mean,

05:35 very quickly we're gonna discuss this in much detail throughout the presentation.

05:39 Well,

05:39 the first step is,

05:40 of course,

05:40 uh,

05:41 a customer files a complaint.

05:43 This complaint is validated by the PSP.

05:47 Or eventually it could be uh through the payment system operator or eventually by

05:52 the regulator.

05:54 The first step is the actual investigation

05:56 and then at the end,

05:57 we come to a resolution.

05:59 This resolution could be in the end

06:01 a refund,

06:03 a reversal,

06:04 some kind of corrective action,

06:06 or probably

06:07 no

06:08 refund at all.

06:10 Uh,

06:11 what are the crucial aspects for consumer protection?

06:13 This is going to be

06:15 the emphasis of this presentation,

06:16 so very quickly here,

06:17 but I'm going to go into much detail,

06:19 uh,

06:19 later on,

06:20 uh,

06:21 there has to be clarity on liability,

06:24 meaning who

06:26 in the payment chain

06:27 will be liable in the event

06:30 there is some kind of dispute.

06:32 To have very clear procedures including timelines,

06:36 timelines for,

06:37 as I said before,

06:39 for investigation,

06:39 resolution,

06:40 etc.

06:40 etc.

06:41 and transparency.

06:44 And finally,

06:45 as part of this overview,

06:46 I just wanted to mention quickly

06:48 what are the most common causes for disputes.

06:50 Uh,

06:51 there are 3

06:52 main,

06:53 uh,

06:54 3 main causes.

06:56 The first one is fraud.

06:58 We have seen this over the last few years,

07:01 especially for fast payments,

07:03 uh,

07:04 what is called authorized push payment or APP scams.

07:09 Uh,

07:10 in

07:11 the payments world,

07:12 there are what we call

07:14 full payments in which

07:15 the beneficiary of the payment is the one that requests

07:19 settlement of the funds

07:21 and then you have push payments in which it is the payer,

07:25 the one that initiates

07:26 the settlement of the funds.

07:28 So,

07:29 it is very difficult

07:31 to reverse a payment

07:32 if the payer actually authorized

07:35 the payment,

07:36 but

07:37 There could be scams

07:39 in this area.

07:40 This is what again we refer to the APP scams,

07:43 uh,

07:44 also as part of social,

07:45 social engineering

07:46 or probably

07:48 there was a theft of the credentials

07:50 of this uh player.

07:52 Uh,

07:53 another important cause

07:54 of dispute is that

07:56 the goods and services that were purchased

07:59 were not received

08:00 or were not received as expected,

08:02 meaning in terms of our quality,

08:04 etc.

08:06 This happens especially

08:07 in e-commerce.

08:09 And finally,

08:10 another main cause is errors.

08:13 This could include

08:14 uh events like misty amounts,

08:17 uh,

08:17 wrong recipient.

08:18 There could be also technical glitches

08:21 uh and and others,

08:22 but,

08:23 but these are,

08:23 are the main ones.

08:25 We do have,

08:25 just to mention that as part of the tools

08:28 of FA,

08:30 we do have specific uh

08:32 document,

08:33 a note,

08:33 a focus note

08:34 on fraud.

08:36 So,

08:36 uh,

08:36 I really recommend for uh our audience,

08:39 our viewers

08:40 to refer to,

08:41 to that focus note for more details on,

08:43 on fraud.

08:48 Then,

08:48 as I said before,

08:49 there are international standards for consumer protection,

08:51 but here we are referring to

08:53 specifically to disputes when it comes to fast payments

08:56 and what are then the unique aspects

08:58 of disputes involving fast payments?

09:00 Well,

09:00 there are,

09:01 I would say,

09:01 uh,

09:02 3 at least.

09:04 The first one is that

09:06 fast payments by their own definition are

09:09 payments that are credited to the beneficiary in real time or close to real time

09:14 and those payments are irrevocable.

09:17 In practice,

09:18 you can imagine that if the payment is created in real-time

09:22 to from,

09:22 let's say to Party B,

09:24 then that Party B can also transfer those funds immediately

09:28 to other parties.

09:29 So,

09:29 it is extremely difficult

09:31 in practice to try to revert the transactions

09:34 and beyond that,

09:35 legally it is,

09:36 uh,

09:36 you can not possible to revert the transaction,

09:40 although there are mechanisms that can be

09:42 adopted and we're going to discuss that.

09:44 Uh,

09:45 expectations of end users.

09:47 Uh,

09:48 fast payments are increasingly used for,

09:50 uh,

09:51 commercial transactions,

09:52 not just for person to person payments,

09:55 and

09:56 in this case

09:57 for

09:58 transactions

09:59 like per person to merchant or person to business,

10:03 then

10:03 users

10:04 are somehow expecting to have

10:07 similar

10:09 uh chargebacks,

10:10 chargeback models as the ones that we have on payment cards,

10:14 credit cards and debit cards,

10:15 hm.

10:16 As I was saying before,

10:18 in payments,

10:18 we have a pool transactions and pull transactions.

10:21 In the,

10:22 in the payment card world,

10:23 these are pool transactions,

10:24 so in that case,

10:26 there has been a model

10:27 already uh for many years

10:30 in which since it is the beneficiary,

10:32 the one that request the settlement of funds,

10:34 there is,

10:35 let's say,

10:36 uh,

10:36 a doubt,

10:37 a potential doubt

10:38 that the transaction is legitimate,

10:40 so,

10:41 uh,

10:41 there is a chargeback model in place,

10:43 and then

10:43 in the case of fast payments,

10:45 There is also an expectation

10:47 when,

10:48 when a person pays a merchant

10:50 that this will happen the same.

10:52 However,

10:53 most fast payment systems

10:55 still lack similar comprehensive

10:57 dispute resolution framework as payment cards.

11:01 And,

11:01 uh,

11:01 as we mentioned before,

11:03 uh,

11:03 there are,

11:04 uh,

11:05 increasingly challenges related to fraud.

11:07 Why?

11:08 Because real-time settlement attracts fraudsters.

11:11 We mentioned before APP scams

11:13 and phishing.

11:14 Uh,

11:15 UK and Brazil,

11:16 among others,

11:17 I mean this is,

11:18 let's say I think that is almost universal right now,

11:21 these,

11:22 but these countries in particular are reporting significant

11:25 APP authorized post payment fraud losses.

11:30 So,

11:32 let's also try to have a

11:33 potential classification of dispute resolution mechanisms.

11:37 Uh,

11:38 I

11:39 put them in 3

11:40 very,

11:41 let's say broad baskets.

11:43 The first one,

11:44 the one to the,

11:45 to the column to the left.

11:47 is,

11:48 uh,

11:49 DRMs or dispute resolution mechanisms that are

11:52 based on legal and regulatory provisions.

11:56 Uh,

11:56 well,

11:57 these provisions establish

11:59 baseline

12:00 statutory protections

12:02 and liability allocation.

12:04 Uh,

12:05 typical laws in which you find this,

12:07 this,

12:07 uh,

12:08 let's say statutory provisions are the funds transfer laws

12:11 or the payment system law,

12:12 etc.

12:14 Uh,

12:16 Here,

12:16 the point is that this is almost always very general.

12:22 Typically,

12:23 laws and regulations do not include all the details that are needed

12:26 for

12:27 a dispute resolution process to be,

12:29 let's say,

12:30 uh,

12:31 easily performed.

12:34 Um,

12:34 central banks

12:35 and other regulators may set refund rights,

12:39 uh,

12:39 specifically defining who is liable

12:41 for what type of transaction,

12:43 uh,

12:43 whether a refund will be total or partial,

12:46 etc.

12:48 There is a case

12:49 in which some

12:50 regulators require,

12:52 uh,

12:52 PSPs to provide unconditional refunds.

12:56 This is the case,

12:56 for example,

12:57 in the UK

12:58 where the payment systems regulator or PSR

13:02 requires these unconditional refunds for any unauthorized transaction.

13:07 Then the second category,

13:09 broad category are

13:10 scheme level-based

13:12 VRMs.

13:14 In this case,

13:16 scheme rules govern dispute reporting.

13:19 liability,

13:20 PSP obligations,

13:21 and so on.

13:23 Typically,

13:24 these rules

13:26 are

13:27 at a much more detailed level

13:29 than

13:29 legal and regulatory provisions.

13:32 They usually include

13:33 specific timelines for handling a dispute,

13:36 escalation paths,

13:38 cooperation requirements between PSPs,

13:39 etc.

13:42 And

13:43 the third category

13:44 are VRMs based.

13:46 On industry initiatives.

13:49 This is the case

13:50 where government regulation is light.

13:54 I'm,

13:54 I'm referring,

13:55 of course,

13:55 for payments,

13:56 when regulation of payments is light.

13:58 In this case,

13:59 industry codes are often developed

14:01 and these are typically adopted

14:03 on a voluntary basis.

14:06 As examples,

14:07 we have the case of Australia's e-payments code

14:10 or South Africa's code of Banking Practice.

14:14 And

14:15 as I will discuss later,

14:17 the three have,

14:18 of course,

14:19 pros and cons.

14:21 We will see that probably the best scenario would

14:23 be a combination of at least 2 of these.

14:28 Well,

14:28 what are the good practices when it comes to

14:31 dispute resolution mechanisms?

14:33 This is actually the core of this presentation.

14:35 We are gonna discuss each of these 6

14:39 practices in detail,

14:40 so I'm gonna just mention them quickly here

14:42 and then

14:43 uh analyze them in detail,

14:45 uh,

14:45 starting from the next slide.

14:47 What are the good practices?

14:48 Well,

14:49 standardized and transparent processes.

14:52 Then to have mechanisms for all types of disputes.

14:57 Uh,

14:58 place emphasis on preventing fraud.

15:02 have a combination of legal scheme and industry-led tools.

15:09 have adequate funding for the dispute resolution mechanism.

15:13 And

15:14 then

15:15 achieve the proper balance between collecting granular data

15:20 and

15:20 privacy.

15:22 OK,

15:22 so let's go one by one.

15:27 So first,

15:28 good practice,

15:29 create standardized and transparent processes.

15:32 Uh,

15:32 for each of these six categories,

15:34 I'm gonna

15:35 first mention what I believe is the core idea.

15:38 So,

15:38 in this case,

15:38 what is the core idea of having standardized and transparent processes?

15:42 Well,

15:43 having

15:44 uniform,

15:45 clear,

15:45 and well-defined processes

15:47 definitely helps to build trust and predictability

15:51 in fast paces.

15:53 What are some of the key actions

15:55 that could be developed?

15:59 Well,

15:59 develop

16:00 standard rules.

16:02 And also I would say detailed rules on

16:05 who

16:06 is liable.

16:07 On documentation that is required.

16:10 On timelines for dispute filing,

16:13 investigation,

16:13 and resolution.

16:16 Ensure that these rules that I mentioned in

16:19 the previous bullet point ensure that these are accessible

16:23 and that they are clear

16:24 to end users and also

16:26 to

16:27 payment service providers.

16:29 And that,

16:30 as I said before,

16:30 that they are accessible,

16:31 meaning that they can be found either

16:33 in a branch or in any digail channel,

16:36 uh,

16:36 etc.

16:38 And also very important

16:40 is

16:41 harmonized processes across the various entities that

16:44 are involved in the dispute resolution process,

16:47 meaning that

16:49 typically

16:50 the,

16:50 for example,

16:51 a payer

16:52 will will raise a dispute with its own payment service provider,

16:56 but then

16:57 it is very likely that the payment system operator will also be involved

17:01 and then probably also the PSP or payment service provider of the payee.

17:05 So,

17:06 these three entities

17:07 The two PSPs,

17:08 one of the parent and one with the P,

17:10 and also the PSO,

17:11 they have to have harmonized processes,

17:13 otherwise it's going to be

17:14 very,

17:14 very difficult and costly

17:16 to handle this dispute.

17:18 As a good example,

17:20 here we have the case of Brazil's peaks regulations.

17:23 In this case,

17:24 uh,

17:25 it is very detailed,

17:26 it is based on law.

17:28 These are,

17:29 uh,

17:29 based again,

17:30 law-based dispute procedures that avoid ambiguity and ensure clarity of growth,

17:35 and

17:35 there is a central bank committee

17:37 that designs and enforces standardized processes for

17:41 dispute resolution in connection with peaked fast payments.

17:49 The second

17:50 best practice

17:51 is to

17:52 have or provide mechanisms for all types of disputes.

17:57 Uh,

17:58 different disputes require different mechanisms,

18:00 as you can imagine,

18:02 mhm.

18:02 Then

18:03 fast payment systems,

18:05 the DRM,

18:06 uh,

18:06 and the dispute resistance mechanisms must cover both end user issues as well as

18:12 inter-participant,

18:13 uh,

18:14 issues.

18:16 4

18:18 Participant disputes.

18:19 Participants,

18:19 I'm referring again to PSPs,

18:21 payment service providers,

18:22 payment system operators,

18:23 and so on.

18:25 Scheme rules should define

18:28 Again,

18:29 who is going to pay,

18:29 meaning where is the liability or

18:31 to what extent there will be a sharing of the liability?

18:35 What are the possibilities and limits and limits

18:38 for direct negotiation between the parties?

18:41 And

18:42 what will be in case they are necessary,

18:44 the arbitration challenges.

18:48 For end users,

18:49 it is very important to

18:51 uh offer multiple accessible channels for filing disputes,

18:54 hm.

18:55 Uh,

18:57 You could have it,

18:58 for example,

18:59 in the,

18:59 in an online portal,

19:00 I mean like in the

19:02 internet banking

19:03 or even in mobile banking

19:05 or to have a call center

19:07 or even in some cases like in the case of a UPI in India,

19:11 that the,

19:12 the channel for filing the dispute could be in in app directly

19:15 in the app.

19:17 Uh,

19:18 also very important in the case of end users is to

19:21 have a mechanism that supports convenient

19:24 data capture.

19:25 I'm referring here to the ability to easily upload documents

19:29 and photos.

19:30 And also efficient case management.

19:34 And then it is also very important

19:36 that

19:37 the

19:38 uh

19:39 the dispute resolution mechanism

19:41 coordinates with

19:43 police

19:44 and other financial authorities

19:46 to simplify fraud reporting.

19:49 Uh,

19:49 as I will mention in maybe one or two slides,

19:52 reporting fraud is very important

19:54 to share information in this area so that other entities

19:58 actually are

19:59 updated on what are the trends

20:01 and actually can fight it.

20:04 And some other practices here

20:07 we have,

20:07 for example,

20:09 card network tools like Eoca and Verify.

20:12 These ones,

20:13 I mean,

20:14 what they do is that

20:15 they send very,

20:17 let's say,

20:18 quick

20:19 and early information

20:20 to the involved actors

20:22 so that unfounded

20:24 chargebacks

20:25 are prevented.

20:27 For example,

20:27 I could say,

20:28 I mean,

20:29 if I'm a fraudulent,

20:31 you know,

20:31 pair,

20:31 I could say that actually I did not receive

20:33 the goods and services that I purchased and I'm

20:36 immediately requesting,

20:37 demanding

20:38 a refund.

20:39 But entities like this actually can help

20:42 the merchants to verify that the goods and services were actually delivered

20:47 and uh as,

20:47 as promised.

20:53 The 3rd best practice.

20:56 Focus on fraud prevention

20:59 and detection.

21:01 The core idea here

21:03 Uh,

21:04 starting from the fact

21:05 that I mentioned before that fraud is now a dominant risk in past payments.

21:10 Then

21:10 ideally,

21:12 DRMs should be

21:14 a last resort

21:15 only after preventive measures have failed.

21:19 Good practices here include

21:22 prioritizing

21:23 end-user education on scams and social engineering.

21:28 Of course,

21:29 this is very easy to say and difficult to do in practice because

21:32 these

21:33 things keep changing

21:34 day by day,

21:35 but still,

21:36 uh,

21:38 Consumers and users have to be informed that these things can happen to them.

21:44 Uh,

21:44 a second good practice here is to use pre-transaction tools,

21:49 I mean,

21:49 before the transaction is actually executed,

21:52 and some of these are,

21:53 for example,

21:54 strong customer authentication.

21:57 And

21:58 confirmation of payee services.

22:00 Uh,

22:02 strong customer authentication,

22:03 remember that I mentioned before,

22:04 the causes of fraud

22:06 is that

22:07 in many cases the credentials

22:09 of the payer

22:10 are stolen.

22:11 So,

22:12 when you have strong customer authentication or SCA,

22:15 this becomes a barrier against this,

22:18 and then also,

22:19 I also mentioned that

22:20 there could be errors

22:21 and probably there was a wrong recipient of the payment.

22:24 When you have this service confirmation of payee,

22:26 this can be significantly reduced.

22:30 Then I was going to jump in real fast as a quick note for our audience that

22:33 we also have a webinar and we also

22:35 have a technical note on prominent overlay services,

22:38 um,

22:39 such as request to pay,

22:40 but really on,

22:40 you know,

22:41 confirmation of payee that gets a little more into

22:43 the details on the back end of all this,

22:45 uh,

22:46 of some of those,

22:47 those pre-transaction tools,

22:49 uh,

22:49 that of course on the website and then back to you.

22:52 Thanks,

22:52 Jose Antonio.

22:54 Thank you,

22:54 Connie.

22:55 That's an excellent point.

22:55 Yes,

22:56 absolutely.

22:57 I mean,

22:57 these things are becoming standard,

22:58 meaning that they are

23:00 no longer things that could be there,

23:01 but they're actually that must be there

23:03 for services to actually be trustworthy.

23:08 Uh,

23:08 the third point here,

23:09 uh,

23:10 establish shared databases of fraudulent accounts and patterns,

23:14 uh,

23:15 including real-time fraud analytics,

23:16 that is what I mentioned before,

23:18 that ideally,

23:19 uh,

23:19 the PSPs that have somehow,

23:21 uh,

23:22 experienced,

23:23 uh,

23:23 fraud

23:24 based on the complaints of their,

23:27 their customers,

23:28 they actually they share this information

23:30 so that everyone

23:32 In the fast payments community

23:34 is informed about the new trends

23:35 and

23:36 And information.

23:38 Here,

23:38 for example,

23:39 the operator

23:40 or the regulator could act as a central monitor

23:43 tracking

23:44 disputes,

23:45 trends,

23:46 uh,

23:46 etc.

23:48 and

23:48 as I said before,

23:49 it's very important to implement feedback loops between

23:52 PSPs

23:53 and

23:54 between PSPs and the operator

23:56 and also the regulator.

23:59 Here,

23:59 the point again is

24:01 to try to prevent fraudulent payments before they actually occur.

24:10 The 4th

24:11 best practice when it comes to dispute resolution mechanisms invas V.

24:16 Implement a combination of different tools,

24:18 legal,

24:19 scheme level,

24:19 and industry

24:21 to cover the various aspects of dispute resolution.

24:24 You may remember that I mentioned these three broad categories

24:26 of DRMs and that I said that ideally a combination

24:31 could work better.

24:32 Mhm.

24:33 This is the core idea actually that I mentioned here,

24:35 that combining tools yields increasingly comprehensive DRMs.

24:40 Uh,

24:40 legal tools,

24:42 as you can imagine,

24:43 these define

24:44 legally enforceable rights and obligations for users,

24:47 PSPs and operators and schemes,

24:49 and they also enable

24:51 cooperation for law enforcement.

24:53 In contrast,

24:55 uh,

24:55 scheme tools this create

24:57 operational level procedures for handling disputes,

25:00 transaction monitoring.

25:03 Fraud handling and so on.

25:04 So,

25:05 to a large extent there is complementarity between these two,

25:10 to put it in simple terms,

25:11 the legal framework says actually what must happen,

25:15 though again

25:16 this is at a very general level

25:19 and then scheme rules

25:20 tell you

25:21 how it should happen.

25:24 And,

25:25 um,

25:26 Also,

25:27 there is a potential tension here

25:29 that uh could be somehow uh solved

25:32 with the complementarity that I mentioned before.

25:35 Why?

25:35 Imagine that

25:37 you only have legal qualification when it comes to dispute handling.

25:41 This of course improves certainty,

25:43 but can reduce flexibility

25:45 when it comes to novel cases

25:47 and all these,

25:48 let's say,

25:48 uh,

25:49 innovation,

25:50 let's say in fraud that we are witnessing.

25:53 Almost every day.

25:54 So,

25:54 having that,

25:55 uh,

25:55 let's say,

25:55 uh,

25:56 uh,

25:56 uh,

25:56 complementary tools is very important.

25:58 One is,

25:59 this is one of the reasons.

26:01 Here you have an example in the UK.

26:03 The mandatory reimbursement for

26:06 uh authorized postpay fraud

26:08 combined

26:08 with

26:09 the

26:10 COP requirement,

26:11 the confirmation of the confirmation of payee requirement.

26:18 The 5th

26:20 main

26:20 uh

26:22 A good practice

26:23 is consider the role of different pricing structures and revenue models

26:28 to ensure the sustainability of the events.

26:32 Uh,

26:32 the point here is that

26:34 These dispute resolution mechanisms are costly.

26:38 These costs include,

26:40 among many others,

26:42 investigation time,

26:43 a coordination between PSPs,

26:46 uh,

26:47 customer support staff,

26:48 fraud analytics and other tools,

26:50 and so on.

26:51 And when you consider that many fast payment transactions are priced at 0,

26:57 especially for

26:58 person to person payments,

27:00 these

27:00 could eventually make VRNs

27:02 unsustainable from a financial standpoint.

27:06 So,

27:07 what are some sustainable models that we have observed in some jurisdictions?

27:12 This is specifically for DRMs.

27:14 Well,

27:15 you could have some form of crop subsidization

27:18 through value-added services provided by

27:21 the fast payment system.

27:23 Or

27:24 there could be a,

27:25 sorry,

27:26 sorry,

27:26 a change in the pricing policy,

27:28 for example,

27:29 uh,

27:29 there could be some small charges.

27:32 Or

27:33 tier service levels,

27:34 for example,

27:35 some charges for

27:37 uh person to business

27:38 payments or business to business payments and maybe still maintain

27:42 zero or very small

27:44 prices for person to person payments.

27:47 Uh,

27:47 another model is definitely to have some public subsidies like,

27:50 like it is the case in Brazil,

27:52 uh,

27:52 and India.

27:53 I'm referring here,

27:54 of course,

27:54 to the case of India UPI and Brazil pigs.

27:58 And also very important to have a very,

28:00 very realistic and robust calculation of the cost of the DRM

28:04 and also to make these calculations transparent so that

28:08 all the parties that are involved have a good idea of what they are getting into.

28:13 And then what is the main takeaway here is that

28:17 the overall pricing

28:19 and or revenue structure

28:21 of the fast payment system

28:23 should reflect the full service stack

28:25 of that fast payment system,

28:27 not just transaction processing,

28:29 but also dispute handling.

28:34 And then coming to the last one.

28:37 Uh,

28:38 There is,

28:39 as we probably,

28:40 you may remember that we mentioned that it's very important

28:43 to have very good data collection

28:46 to handle fraud.

28:48 To handle disputes,

28:49 to make good analysis,

28:50 and so on.

28:52 But there has to be a balance between collecting this granular information and also

28:57 the privacy of the parties involved.

29:01 What are some good practices?

29:03 Uh,

29:04 collecting

29:05 transaction data

29:07 as granular as possible is very important.

29:10 This could include timestamps,

29:12 uh,

29:13 ID numbers,

29:14 alliances,

29:15 authentication method,

29:17 device info,

29:18 uh,

29:19 the results of the confirmation of PE,

29:21 uh,

29:22 process,

29:23 and so on.

29:24 Very rarely there is a need to actually

29:27 have,

29:27 you know,

29:27 the name of the person here,

29:30 right?

29:30 But still,

29:31 this is very uh granular data.

29:35 Uh,

29:35 adopt standardized messaging and formats,

29:38 in particular ISO 20022.

29:42 Uh,

29:43 as I mentioned before,

29:44 using aggregate and or depersonalized data for

29:47 further analytics and registries is typically sufficient.

29:50 Again,

29:51 you do not need to include in this type of analysis the name of the person

29:54 or any other variable through which that person can be identified,

29:58 person or,

29:58 or,

29:59 or firm,

29:59 of course.

30:01 And also design

30:03 data sharing protocols early in the development of the fast payment mechanism

30:08 to avoid retrofit costs and compliance risks.

30:11 So,

30:11 here again,

30:11 the point is

30:13 by doing this,

30:14 uh,

30:15 enable faster,

30:17 more accurate and accountable dispute handling while maintaining user privacy.

30:25 So,

30:26 after this discussion on best practices,

30:28 let's try to go to some counter examples.

30:32 Here we have

30:33 9 examples.

30:35 Again,

30:36 I really recommend

30:37 our audience to go to

30:39 this specific focus node in which all these country cases

30:43 are discussed in much more detail than here.

30:45 Uh,

30:46 uh,

30:47 for the purposes,

30:47 for the purposes of this webinar,

30:48 I'm only going to go

30:50 through some of the main points of one of these cases to make a,

30:53 to try to,

30:54 to contrast the differences,

30:56 uh.

30:57 In the case of Australia,

31:00 Uh

31:01 In Australia,

31:02 the fast payment system MPP,

31:04 this is operated by a private sector entity.

31:07 Mhm.

31:07 What is the approach then?

31:09 It is essentially

31:10 scheme level,

31:12 meaning that the operator

31:13 of MPP is the one that is

31:15 setting

31:16 the rules and procedures

31:18 and it is complemented

31:20 with a voluntary codes,

31:21 a voluntary code,

31:23 the

31:24 Australia e-payments code.

31:27 Uh,

31:28 But you can see the case of Bahrain

31:31 that is somehow similar.

31:33 In this case,

31:34 Benefit Co if the operator is a private sector entity,

31:38 but

31:39 The mechanism they have developed

31:41 is

31:42 much less robust.

31:44 Uh,

31:45 they only have a centralized call center,

31:47 and

31:48 they actually,

31:49 in most cases,

31:50 uh,

31:51 they

31:52 try to somehow get to a bilateral resolution,

31:55 uh,

31:56 of,

31:56 uh,

31:56 dispute between PSPs.

31:59 Mhm.

32:00 In this case,

32:01 uh,

32:01 Bahrain,

32:02 if you read the,

32:02 the case study in the focus note,

32:04 you will see that in this case,

32:06 customers are,

32:07 in most cases

32:08 directly liable,

32:09 uh,

32:10 for,

32:10 for,

32:11 for most frauds.

32:14 In the case of Brazil and Mexico,

32:16 these

32:17 fast payment systems are operated by central banks.

32:20 So you can imagine that the approach to dispute resolution is

32:24 legal and regulatory based,

32:26 mainly.

32:28 Uh,

32:29 but

32:30 in the case

32:31 of both Brazil and Mexico,

32:33 it is complemented with scheme level provisions.

32:36 I mean,

32:37 the,

32:37 the,

32:37 the operator of picks and spade

32:41 beyond

32:41 the legal provision

32:42 in the

32:44 rules of the system

32:45 have actually uh included things as

32:48 uh what are the timelines

32:50 for uh handling,

32:51 sorry,

32:51 for filing a dispute,

32:53 the times for investigation,

32:55 again,

32:55 who is liable and to what extent,

32:58 uh,

32:58 and so on.

33:00 Then you have,

33:01 for example,

33:01 the case of South Africa.

33:03 South Africa is also

33:04 uh RTC

33:06 with time clearing,

33:07 uh,

33:08 is operated by a private sector entity.

33:10 In South Africa,

33:12 there is

33:13 very,

33:13 very light,

33:15 uh,

33:16 official,

33:17 uh,

33:17 regulation and oversight when it comes to payments.

33:20 In this case,

33:21 there is to a large extent self-regulation,

33:24 so

33:25 essentially there is only a voluntary code of banking practice

33:28 that is complemented

33:30 by an ombudsman.

33:32 I mean,

33:33 in essence,

33:34 uh,

33:35 here,

33:36 customers can escalate the problem to the ombudsman

33:39 in case they

33:41 believe that

33:42 the,

33:43 uh,

33:43 their payment system provider.

33:45 The payment,

33:45 sorry,

33:46 the payment payment service provider

33:48 has not followed

33:50 these codes

33:51 uh as it is supposed to,

33:53 but remember again that

33:55 in most cases adoption of adoption of these codes is voluntary.

34:00 And then let's go to the case of the US.

34:02 In the US

34:03 they have

34:04 at least,

34:05 let's say,

34:06 two

34:06 well-known fast payment systems,

34:08 RTP and FetNA.

34:10 One is operated by the private sector and the

34:11 other one is operated by the Federal Reserve,

34:13 which,

34:13 as you know,

34:14 is a central bank,

34:15 but both are based on regulation.

34:18 I mean the dispute resolution approach

34:20 is based on regulation,

34:21 specifically regulation E

34:23 and

34:24 UCC meaning Uniform Commercial Code 4A,

34:27 and there are also scheme level rules

34:30 and

34:31 because of this combination of regulation and scheme level rules,

34:34 you have also

34:35 detailed provisions.

34:36 For example,

34:37 there is a

34:38 Uh,

34:38 60 to 90 day report window,

34:40 I mean,

34:41 that is the period

34:42 of time in which you can report,

34:43 uh,

34:44 if you can file a complaint

34:46 and then

34:46 there is a 10-day

34:48 investigation period,

34:49 uh,

34:49 and etc.

34:50 So,

34:51 uh,

34:52 again,

34:53 uh,

34:53 I suggest that you go to the document and read

34:56 more about these 9 cases.

35:02 So,

35:02 then

35:03 let me

35:04 try to go through this slide that uh highlights

35:08 the main aspects of uh dispute resolution

35:12 framework

35:13 and how this approach.

35:16 How are these approached

35:17 based on whether the mechanism is centralized,

35:20 regulatory led,

35:21 industry code,

35:22 hybrid,

35:22 etc.

35:24 Well,

35:24 the first,

35:25 uh,

35:26 main feature or dimension.

35:29 Primary liability.

35:32 Uh,

35:33 well,

35:33 in the case of a

35:35 regulatory led or uh based on law,

35:39 Liability is precisely determined by law

35:42 and under the central bank rules,

35:45 but again,

35:45 remember that this is

35:47 very good in the sense that it is uh predictable,

35:51 but

35:52 it will be in most cases determined at a very high level.

35:58 If,

35:59 if,

35:59 if it is an industry code

36:02 that is used,

36:03 then

36:04 primary liability

36:05 is

36:07 usually shared or is voluntary

36:09 because adoption of the code is voluntary.

36:12 Mhm.

36:13 And in the case of a hybrid model,

36:15 then typically the scheme rules will define

36:18 who is liable

36:19 and

36:20 whether it is for the total amount,

36:22 partial,

36:22 and so on.

36:24 The second dimension,

36:25 consumer recourse.

36:28 Uh,

36:28 in the case of a

36:31 regulatory-led

36:32 DRM,

36:34 well,

36:34 there is typically a regulator.

36:37 uh,

36:38 to,

36:39 to which you can actually recur or

36:42 also a formal ombudsman in some cases.

36:46 If an industry code approach is used,

36:48 then typically it is an industry ombudsman.

36:51 Again,

36:51 it's not,

36:52 uh,

36:53 uh,

36:54 well,

36:54 it's formal,

36:54 but it's not,

36:55 let's say,

36:55 uh,

36:56 uh,

36:57 this was not report to,

36:58 to actually to,

36:59 to,

37:00 to,

37:00 to the central bank or to the regulator,

37:03 and still voluntary.

37:07 Dispute challenges.

37:09 Uh,

37:10 in the case of a regulatory-led approach,

37:13 in many cases,

37:14 there will be a central platform in which you can file complaints

37:19 or in app,

37:19 as it is the case of

37:21 uh UPI.

37:23 Uh

37:25 I,

37:26 if it is an industry code

37:28 uh DRM,

37:30 well,

37:30 yes,

37:31 PSPs are at the front line.

37:33 Mhm,

37:33 I mean,

37:34 they are the ones that are

37:35 supposed to handle all the disputes,

37:37 mhm,

37:38 and eventually this can be escalated to an ombudsman,

37:42 but the approach is very different because it is,

37:44 there is no central platform,

37:45 but directly

37:46 the PSP is involved.

37:49 Uh,

37:50 again,

37:50 refund mechanisms,

37:51 they are legally mandated

37:52 in the,

37:53 in the first case

37:54 and

37:55 in the case of the industry code,

37:57 uh,

37:57 DRMs,

37:58 these are essentially voluntary.

38:01 Uh,

38:02 Then let's go to

38:04 the 2nd to last,

38:05 the oversight entity.

38:08 Uh,

38:08 as you can imagine in a regulatory led ERM,

38:11 this mechanism is usually

38:13 overseen by the central bank,

38:15 hm.

38:17 Uh,

38:18 in the case of Brazil,

38:19 it is directly central bank.

38:20 In the case of,

38:21 uh,

38:21 India,

38:22 it is the RBI,

38:23 Reserve Bank of India,

38:24 even if

38:25 UPI is not operated by,

38:27 uh,

38:27 RBI.

38:29 But in the case of an industry,

38:31 industry,

38:31 uh,

38:32 code-based DRM,

38:34 actually the identity will be

38:36 the same industry body.

38:39 So,

38:39 what are the key takeaways of

38:41 these differences?

38:43 Well,

38:43 in a

38:44 legal or regulatory-led DRM,

38:47 a strong regulatory framework ensures uniform protection.

38:51 But

38:53 there is less flexibility.

38:56 In an industry code-based DRM,

38:59 voluntary codes raise coverage and awareness,

39:01 but may lack in compliance.

39:04 And hybrid models as argued before,

39:07 they usually balance flexibility and trust.

39:11 In

39:12 the various parties involved.

39:16 So,

39:18 what is the conclusion?

39:20 Uh,

39:21 successful dispute resolution mechanisms depend on clear liability regimes.

39:27 Collaboration between regulations and industry

39:30 and consumer-centric dispute handling.

39:36 Robust DRMs.

39:38 When I mention robust,

39:39 I'm referring to standardized

39:41 legally sound.

39:43 Uh,

39:43 details,

39:44 etc.

39:45 These are essential to protect consumers and

39:48 maintain

39:49 trust in fast payments.

39:52 Although fast payments are irrevocable,

39:56 Still,

39:57 refunds or returns can be structured.

40:00 Under

40:01 DRM frameworks.

40:04 BRMs

40:06 should keep on evolving

40:07 as fast as fast payments mature

40:10 from general guidelines

40:11 into formalized and

40:14 actually more comprehensive

40:16 mechanisms

40:17 and

40:18 finally,

40:18 but very important,

40:20 fraud prevention strategies

40:21 are

40:22 also a key element of

40:24 every robust DRA.

40:28 So,

40:30 That's it

40:31 for,

40:31 for me for now,

40:32 Colin.

40:34 Let me.

40:34 That was,

40:34 that was wonderful.

40:36 Thank you so much though.

40:37 That hit it right on the,

40:38 right on the nose.

40:39 If you didn't just walk us through,

40:40 you know,

40:41 what

40:42 to think through,

40:43 but how,

40:45 you know,

40:45 some of this combination of legal and different

40:47 scheme levels and thinking through buy-in and coverage,

40:50 but also,

40:51 you know,

40:51 commitment and making sure people are on board

40:53 and prices and how to really operationalize this.

40:57 Long term as well as thinking,

40:58 you know,

40:58 flexibly

41:00 about,

41:00 about DRM,

41:01 uh,

41:02 as well as just like the clarity.

41:04 And this gets back to some of the key

41:05 points about launching and scaling fast payment systems,

41:08 about building trust

41:09 and interoperability

41:11 has incredible benefits,

41:12 but as,

41:13 as long as we do it correctly,

41:15 uh,

41:15 and,

41:15 and with that kind of consumer user focused brain.

41:19 Uh,

41:19 and which is why

41:21 DRMs are so important.

41:22 So

41:23 with that,

41:23 thank you so much.

41:25 Thank you to our audience,

41:26 and we will see you all next time.

41:29 OK.

41:29 Thank you again very much.

41:30 Thank you to everyone,

41:32 and it's been a pleasure.

41:34 Thanks everyone.

41:35 Bye bye.

41:36 Goodbye.

showAllTimestamps
no
transcript
My name is Colin Coulter, and I am a consultant for the World Bank's Project FAST. FAST, or frictionless Affordable, Safe, Timely Transactions, is a flagship project of the World Bank and focuses on accelerating the adoption of fast payment systems in low and moderate income countries. Generously supported by the Gates Foundation, Project Fast works to expand knowledge, build capacity in key institutions, raise awareness, coordinate global stakeholders, and provide technical assistance for the adoption of fast payment systems around the world. As a reminder, all of the work of Project Fast, as well as the recording of this webinar, can be found on a dedicated website, fastpayments.worldbank.org. Today we are continuing our webinar series this time focusing on the role of dispute resolution mechanisms in fast payment systems, and we really have the perfect guest to lead us through that conversation, Jose Antonio Garcia Garcia Luna. Jose Antonio is currently a senior payments advisor for the payment systems development group, the World Bank. He's mostly involved in assisting countries in the implementation of fast payment systems. In assessing payment and other settlement systems on the basis of the CPMI IOSCO PFMIs and in financial inclusion initiatives like the World Bank Group CPMI, uh, work on payments aspects of financial inclusion. He's also been involved in the production of international standards and best practices. Most recent country engagements include Albania, Chile, Colombia, Dominican Republic, Indonesia, Paraguay, South South Africa, Uruguay, and Vietnam. Antonio has held senior positions across finance, education, payments, investment, and credit. He's led the program program on financial literacy at the Universidad Ahuac in Mexico City, and he has served as deputy CEO of Infonico, a state-owned financial institution based in Mexico City that provides consumer loans to low-income workers. Mr. Garcia has also been a senior payment system specialist at the World Bank, a senior economist at the Center for Latin American Monetary Studies, and a credit analysis specialist Abanco and Bursa, both in Mexico City. And so we really have the absolute perfect guest with us today, uh, to walk us through that conversation. And so with that, Jose Antonio, I hand the floor to you. Thank you so much, Colin. It's really a pleasure to participate in this new webinar. Uh, today, we have a very, very interesting topic. It's about, uh, solving, trying to solve in a in a balanced manner disputes that may arise as a result of payment activity, in particular, fast payments. Uh, let me share my screen so that we can begin. OK. OK. OK. Here we go. So, let's start. Uh, when we are talking about a dispute, what are we referring to for the specific context of payments? Well, we're going to adopt this definition. Disputes refer to payments that have been executed, but that are contested by any of the parties involved. And disputes may also refer to other payment activities that are contested. For example, uh, a payment that actually was not created to a beneficiary, I mean the payment was probably not executed and there might be a dispute on why it was not executed as expected by the payer. Uh, in disputes, as you can imagine, we have, uh, at least 2 parties involved and we're gonna divide them into two broad categories. The first one for the purposes of this uh webinar, uh, are those, and the first category involves end users. Uh, end users that are involved in a dispute, it could be, for example, a payer versus its payment service provider or a payer versus a payee or the payee versus its PSP payments service provider. And the second broad category is the one that refers to disputes that have to do with differences between payment entities. Payment system operators and so on. This means that there is a dispute between one PSP and another PSP or a PSP versus the payment system operator or PSO. So, these are the two broad categories. However, for the purpose of this webinar, we are going to focus mainly on disputes that involve end users. In this area, We have some international standards already in place. These are the OECD G20 financial consumer protection principles. These standards call for accessible, fair, efficient consumer campaign handling. And importantly, these are intended to apply to any type of financial services. I mean, these were, these were not created specifically for payments, but they do include payments. Uh, then for disputes that involve end users, what is the typical flow here, I mean, very quickly we're gonna discuss this in much detail throughout the presentation. Well, the first step is, of course, uh, a customer files a complaint. This complaint is validated by the PSP. Or eventually it could be uh through the payment system operator or eventually by the regulator. The first step is the actual investigation and then at the end, we come to a resolution. This resolution could be in the end a refund, a reversal, some kind of corrective action, or probably no refund at all. Uh, what are the crucial aspects for consumer protection? This is going to be the emphasis of this presentation, so very quickly here, but I'm going to go into much detail, uh, later on, uh, there has to be clarity on liability, meaning who in the payment chain will be liable in the event there is some kind of dispute. To have very clear procedures including timelines, timelines for, as I said before, for investigation, resolution, etc. etc. and transparency. And finally, as part of this overview, I just wanted to mention quickly what are the most common causes for disputes. Uh, there are 3 main, uh, 3 main causes. The first one is fraud. We have seen this over the last few years, especially for fast payments, uh, what is called authorized push payment or APP scams. Uh, in the payments world, there are what we call full payments in which the beneficiary of the payment is the one that requests settlement of the funds and then you have push payments in which it is the payer, the one that initiates the settlement of the funds. So, it is very difficult to reverse a payment if the payer actually authorized the payment, but There could be scams in this area. This is what again we refer to the APP scams, uh, also as part of social, social engineering or probably there was a theft of the credentials of this uh player. Uh, another important cause of dispute is that the goods and services that were purchased were not received or were not received as expected, meaning in terms of our quality, etc. This happens especially in e-commerce. And finally, another main cause is errors. This could include uh events like misty amounts, uh, wrong recipient. There could be also technical glitches uh and and others, but, but these are, are the main ones. We do have, just to mention that as part of the tools of FA, we do have specific uh document, a note, a focus note on fraud. So, uh, I really recommend for uh our audience, our viewers to refer to, to that focus note for more details on, on fraud. Then, as I said before, there are international standards for consumer protection, but here we are referring to specifically to disputes when it comes to fast payments and what are then the unique aspects of disputes involving fast payments? Well, there are, I would say, uh, 3 at least. The first one is that fast payments by their own definition are payments that are credited to the beneficiary in real time or close to real time and those payments are irrevocable. In practice, you can imagine that if the payment is created in real-time to from, let's say to Party B, then that Party B can also transfer those funds immediately to other parties. So, it is extremely difficult in practice to try to revert the transactions and beyond that, legally it is, uh, you can not possible to revert the transaction, although there are mechanisms that can be adopted and we're going to discuss that. Uh, expectations of end users. Uh, fast payments are increasingly used for, uh, commercial transactions, not just for person to person payments, and in this case for transactions like per person to merchant or person to business, then users are somehow expecting to have similar uh chargebacks, chargeback models as the ones that we have on payment cards, credit cards and debit cards, hm. As I was saying before, in payments, we have a pool transactions and pull transactions. In the, in the payment card world, these are pool transactions, so in that case, there has been a model already uh for many years in which since it is the beneficiary, the one that request the settlement of funds, there is, let's say, uh, a doubt, a potential doubt that the transaction is legitimate, so, uh, there is a chargeback model in place, and then in the case of fast payments, There is also an expectation when, when a person pays a merchant that this will happen the same. However, most fast payment systems still lack similar comprehensive dispute resolution framework as payment cards. And, uh, as we mentioned before, uh, there are, uh, increasingly challenges related to fraud. Why? Because real-time settlement attracts fraudsters. We mentioned before APP scams and phishing. Uh, UK and Brazil, among others, I mean this is, let's say I think that is almost universal right now, these, but these countries in particular are reporting significant APP authorized post payment fraud losses. So, let's also try to have a potential classification of dispute resolution mechanisms. Uh, I put them in 3 very, let's say broad baskets. The first one, the one to the, to the column to the left. is, uh, DRMs or dispute resolution mechanisms that are based on legal and regulatory provisions. Uh, well, these provisions establish baseline statutory protections and liability allocation. Uh, typical laws in which you find this, this, uh, let's say statutory provisions are the funds transfer laws or the payment system law, etc. Uh, Here, the point is that this is almost always very general. Typically, laws and regulations do not include all the details that are needed for a dispute resolution process to be, let's say, uh, easily performed. Um, central banks and other regulators may set refund rights, uh, specifically defining who is liable for what type of transaction, uh, whether a refund will be total or partial, etc. There is a case in which some regulators require, uh, PSPs to provide unconditional refunds. This is the case, for example, in the UK where the payment systems regulator or PSR requires these unconditional refunds for any unauthorized transaction. Then the second category, broad category are scheme level-based VRMs. In this case, scheme rules govern dispute reporting. liability, PSP obligations, and so on. Typically, these rules are at a much more detailed level than legal and regulatory provisions. They usually include specific timelines for handling a dispute, escalation paths, cooperation requirements between PSPs, etc. And the third category are VRMs based. On industry initiatives. This is the case where government regulation is light. I'm, I'm referring, of course, for payments, when regulation of payments is light. In this case, industry codes are often developed and these are typically adopted on a voluntary basis. As examples, we have the case of Australia's e-payments code or South Africa's code of Banking Practice. And as I will discuss later, the three have, of course, pros and cons. We will see that probably the best scenario would be a combination of at least 2 of these. Well, what are the good practices when it comes to dispute resolution mechanisms? This is actually the core of this presentation. We are gonna discuss each of these 6 practices in detail, so I'm gonna just mention them quickly here and then uh analyze them in detail, uh, starting from the next slide. What are the good practices? Well, standardized and transparent processes. Then to have mechanisms for all types of disputes. Uh, place emphasis on preventing fraud. have a combination of legal scheme and industry-led tools. have adequate funding for the dispute resolution mechanism. And then achieve the proper balance between collecting granular data and privacy. OK, so let's go one by one. So first, good practice, create standardized and transparent processes. Uh, for each of these six categories, I'm gonna first mention what I believe is the core idea. So, in this case, what is the core idea of having standardized and transparent processes? Well, having uniform, clear, and well-defined processes definitely helps to build trust and predictability in fast paces. What are some of the key actions that could be developed? Well, develop standard rules. And also I would say detailed rules on who is liable. On documentation that is required. On timelines for dispute filing, investigation, and resolution. Ensure that these rules that I mentioned in the previous bullet point ensure that these are accessible and that they are clear to end users and also to payment service providers. And that, as I said before, that they are accessible, meaning that they can be found either in a branch or in any digail channel, uh, etc. And also very important is harmonized processes across the various entities that are involved in the dispute resolution process, meaning that typically the, for example, a payer will will raise a dispute with its own payment service provider, but then it is very likely that the payment system operator will also be involved and then probably also the PSP or payment service provider of the payee. So, these three entities The two PSPs, one of the parent and one with the P, and also the PSO, they have to have harmonized processes, otherwise it's going to be very, very difficult and costly to handle this dispute. As a good example, here we have the case of Brazil's peaks regulations. In this case, uh, it is very detailed, it is based on law. These are, uh, based again, law-based dispute procedures that avoid ambiguity and ensure clarity of growth, and there is a central bank committee that designs and enforces standardized processes for dispute resolution in connection with peaked fast payments. The second best practice is to have or provide mechanisms for all types of disputes. Uh, different disputes require different mechanisms, as you can imagine, mhm. Then fast payment systems, the DRM, uh, and the dispute resistance mechanisms must cover both end user issues as well as inter-participant, uh, issues. 4 Participant disputes. Participants, I'm referring again to PSPs, payment service providers, payment system operators, and so on. Scheme rules should define Again, who is going to pay, meaning where is the liability or to what extent there will be a sharing of the liability? What are the possibilities and limits and limits for direct negotiation between the parties? And what will be in case they are necessary, the arbitration challenges. For end users, it is very important to uh offer multiple accessible channels for filing disputes, hm. Uh, You could have it, for example, in the, in an online portal, I mean like in the internet banking or even in mobile banking or to have a call center or even in some cases like in the case of a UPI in India, that the, the channel for filing the dispute could be in in app directly in the app. Uh, also very important in the case of end users is to have a mechanism that supports convenient data capture. I'm referring here to the ability to easily upload documents and photos. And also efficient case management. And then it is also very important that the uh the dispute resolution mechanism coordinates with police and other financial authorities to simplify fraud reporting. Uh, as I will mention in maybe one or two slides, reporting fraud is very important to share information in this area so that other entities actually are updated on what are the trends and actually can fight it. And some other practices here we have, for example, card network tools like Eoca and Verify. These ones, I mean, what they do is that they send very, let's say, quick and early information to the involved actors so that unfounded chargebacks are prevented. For example, I could say, I mean, if I'm a fraudulent, you know, pair, I could say that actually I did not receive the goods and services that I purchased and I'm immediately requesting, demanding a refund. But entities like this actually can help the merchants to verify that the goods and services were actually delivered and uh as, as promised. The 3rd best practice. Focus on fraud prevention and detection. The core idea here Uh, starting from the fact that I mentioned before that fraud is now a dominant risk in past payments. Then ideally, DRMs should be a last resort only after preventive measures have failed. Good practices here include prioritizing end-user education on scams and social engineering. Of course, this is very easy to say and difficult to do in practice because these things keep changing day by day, but still, uh, Consumers and users have to be informed that these things can happen to them. Uh, a second good practice here is to use pre-transaction tools, I mean, before the transaction is actually executed, and some of these are, for example, strong customer authentication. And confirmation of payee services. Uh, strong customer authentication, remember that I mentioned before, the causes of fraud is that in many cases the credentials of the payer are stolen. So, when you have strong customer authentication or SCA, this becomes a barrier against this, and then also, I also mentioned that there could be errors and probably there was a wrong recipient of the payment. When you have this service confirmation of payee, this can be significantly reduced. Then I was going to jump in real fast as a quick note for our audience that we also have a webinar and we also have a technical note on prominent overlay services, um, such as request to pay, but really on, you know, confirmation of payee that gets a little more into the details on the back end of all this, uh, of some of those, those pre-transaction tools, uh, that of course on the website and then back to you. Thanks, Jose Antonio. Thank you, Connie. That's an excellent point. Yes, absolutely. I mean, these things are becoming standard, meaning that they are no longer things that could be there, but they're actually that must be there for services to actually be trustworthy. Uh, the third point here, uh, establish shared databases of fraudulent accounts and patterns, uh, including real-time fraud analytics, that is what I mentioned before, that ideally, uh, the PSPs that have somehow, uh, experienced, uh, fraud based on the complaints of their, their customers, they actually they share this information so that everyone In the fast payments community is informed about the new trends and And information. Here, for example, the operator or the regulator could act as a central monitor tracking disputes, trends, uh, etc. and as I said before, it's very important to implement feedback loops between PSPs and between PSPs and the operator and also the regulator. Here, the point again is to try to prevent fraudulent payments before they actually occur. The 4th best practice when it comes to dispute resolution mechanisms invas V. Implement a combination of different tools, legal, scheme level, and industry to cover the various aspects of dispute resolution. You may remember that I mentioned these three broad categories of DRMs and that I said that ideally a combination could work better. Mhm. This is the core idea actually that I mentioned here, that combining tools yields increasingly comprehensive DRMs. Uh, legal tools, as you can imagine, these define legally enforceable rights and obligations for users, PSPs and operators and schemes, and they also enable cooperation for law enforcement. In contrast, uh, scheme tools this create operational level procedures for handling disputes, transaction monitoring. Fraud handling and so on. So, to a large extent there is complementarity between these two, to put it in simple terms, the legal framework says actually what must happen, though again this is at a very general level and then scheme rules tell you how it should happen. And, um, Also, there is a potential tension here that uh could be somehow uh solved with the complementarity that I mentioned before. Why? Imagine that you only have legal qualification when it comes to dispute handling. This of course improves certainty, but can reduce flexibility when it comes to novel cases and all these, let's say, uh, innovation, let's say in fraud that we are witnessing. Almost every day. So, having that, uh, let's say, uh, uh, uh, complementary tools is very important. One is, this is one of the reasons. Here you have an example in the UK. The mandatory reimbursement for uh authorized postpay fraud combined with the COP requirement, the confirmation of the confirmation of payee requirement. The 5th main uh A good practice is consider the role of different pricing structures and revenue models to ensure the sustainability of the events. Uh, the point here is that These dispute resolution mechanisms are costly. These costs include, among many others, investigation time, a coordination between PSPs, uh, customer support staff, fraud analytics and other tools, and so on. And when you consider that many fast payment transactions are priced at 0, especially for person to person payments, these could eventually make VRNs unsustainable from a financial standpoint. So, what are some sustainable models that we have observed in some jurisdictions? This is specifically for DRMs. Well, you could have some form of crop subsidization through value-added services provided by the fast payment system. Or there could be a, sorry, sorry, a change in the pricing policy, for example, uh, there could be some small charges. Or tier service levels, for example, some charges for uh person to business payments or business to business payments and maybe still maintain zero or very small prices for person to person payments. Uh, another model is definitely to have some public subsidies like, like it is the case in Brazil, uh, and India. I'm referring here, of course, to the case of India UPI and Brazil pigs. And also very important to have a very, very realistic and robust calculation of the cost of the DRM and also to make these calculations transparent so that all the parties that are involved have a good idea of what they are getting into. And then what is the main takeaway here is that the overall pricing and or revenue structure of the fast payment system should reflect the full service stack of that fast payment system, not just transaction processing, but also dispute handling. And then coming to the last one. Uh, There is, as we probably, you may remember that we mentioned that it's very important to have very good data collection to handle fraud. To handle disputes, to make good analysis, and so on. But there has to be a balance between collecting this granular information and also the privacy of the parties involved. What are some good practices? Uh, collecting transaction data as granular as possible is very important. This could include timestamps, uh, ID numbers, alliances, authentication method, device info, uh, the results of the confirmation of PE, uh, process, and so on. Very rarely there is a need to actually have, you know, the name of the person here, right? But still, this is very uh granular data. Uh, adopt standardized messaging and formats, in particular ISO 20022. Uh, as I mentioned before, using aggregate and or depersonalized data for further analytics and registries is typically sufficient. Again, you do not need to include in this type of analysis the name of the person or any other variable through which that person can be identified, person or, or, or firm, of course. And also design data sharing protocols early in the development of the fast payment mechanism to avoid retrofit costs and compliance risks. So, here again, the point is by doing this, uh, enable faster, more accurate and accountable dispute handling while maintaining user privacy. So, after this discussion on best practices, let's try to go to some counter examples. Here we have 9 examples. Again, I really recommend our audience to go to this specific focus node in which all these country cases are discussed in much more detail than here. Uh, uh, for the purposes, for the purposes of this webinar, I'm only going to go through some of the main points of one of these cases to make a, to try to, to contrast the differences, uh. In the case of Australia, Uh In Australia, the fast payment system MPP, this is operated by a private sector entity. Mhm. What is the approach then? It is essentially scheme level, meaning that the operator of MPP is the one that is setting the rules and procedures and it is complemented with a voluntary codes, a voluntary code, the Australia e-payments code. Uh, But you can see the case of Bahrain that is somehow similar. In this case, Benefit Co if the operator is a private sector entity, but The mechanism they have developed is much less robust. Uh, they only have a centralized call center, and they actually, in most cases, uh, they try to somehow get to a bilateral resolution, uh, of, uh, dispute between PSPs. Mhm. In this case, uh, Bahrain, if you read the, the case study in the focus note, you will see that in this case, customers are, in most cases directly liable, uh, for, for, for most frauds. In the case of Brazil and Mexico, these fast payment systems are operated by central banks. So you can imagine that the approach to dispute resolution is legal and regulatory based, mainly. Uh, but in the case of both Brazil and Mexico, it is complemented with scheme level provisions. I mean, the, the, the operator of picks and spade beyond the legal provision in the rules of the system have actually uh included things as uh what are the timelines for uh handling, sorry, for filing a dispute, the times for investigation, again, who is liable and to what extent, uh, and so on. Then you have, for example, the case of South Africa. South Africa is also uh RTC with time clearing, uh, is operated by a private sector entity. In South Africa, there is very, very light, uh, official, uh, regulation and oversight when it comes to payments. In this case, there is to a large extent self-regulation, so essentially there is only a voluntary code of banking practice that is complemented by an ombudsman. I mean, in essence, uh, here, customers can escalate the problem to the ombudsman in case they believe that the, uh, their payment system provider. The payment, sorry, the payment payment service provider has not followed these codes uh as it is supposed to, but remember again that in most cases adoption of adoption of these codes is voluntary. And then let's go to the case of the US. In the US they have at least, let's say, two well-known fast payment systems, RTP and FetNA. One is operated by the private sector and the other one is operated by the Federal Reserve, which, as you know, is a central bank, but both are based on regulation. I mean the dispute resolution approach is based on regulation, specifically regulation E and UCC meaning Uniform Commercial Code 4A, and there are also scheme level rules and because of this combination of regulation and scheme level rules, you have also detailed provisions. For example, there is a Uh, 60 to 90 day report window, I mean, that is the period of time in which you can report, uh, if you can file a complaint and then there is a 10-day investigation period, uh, and etc. So, uh, again, uh, I suggest that you go to the document and read more about these 9 cases. So, then let me try to go through this slide that uh highlights the main aspects of uh dispute resolution framework and how this approach. How are these approached based on whether the mechanism is centralized, regulatory led, industry code, hybrid, etc. Well, the first, uh, main feature or dimension. Primary liability. Uh, well, in the case of a regulatory led or uh based on law, Liability is precisely determined by law and under the central bank rules, but again, remember that this is very good in the sense that it is uh predictable, but it will be in most cases determined at a very high level. If, if, if it is an industry code that is used, then primary liability is usually shared or is voluntary because adoption of the code is voluntary. Mhm. And in the case of a hybrid model, then typically the scheme rules will define who is liable and whether it is for the total amount, partial, and so on. The second dimension, consumer recourse. Uh, in the case of a regulatory-led DRM, well, there is typically a regulator. uh, to, to which you can actually recur or also a formal ombudsman in some cases. If an industry code approach is used, then typically it is an industry ombudsman. Again, it's not, uh, uh, well, it's formal, but it's not, let's say, uh, uh, this was not report to, to actually to, to, to, to the central bank or to the regulator, and still voluntary. Dispute challenges. Uh, in the case of a regulatory-led approach, in many cases, there will be a central platform in which you can file complaints or in app, as it is the case of uh UPI. Uh I, if it is an industry code uh DRM, well, yes, PSPs are at the front line. Mhm, I mean, they are the ones that are supposed to handle all the disputes, mhm, and eventually this can be escalated to an ombudsman, but the approach is very different because it is, there is no central platform, but directly the PSP is involved. Uh, again, refund mechanisms, they are legally mandated in the, in the first case and in the case of the industry code, uh, DRMs, these are essentially voluntary. Uh, Then let's go to the 2nd to last, the oversight entity. Uh, as you can imagine in a regulatory led ERM, this mechanism is usually overseen by the central bank, hm. Uh, in the case of Brazil, it is directly central bank. In the case of, uh, India, it is the RBI, Reserve Bank of India, even if UPI is not operated by, uh, RBI. But in the case of an industry, industry, uh, code-based DRM, actually the identity will be the same industry body. So, what are the key takeaways of these differences? Well, in a legal or regulatory-led DRM, a strong regulatory framework ensures uniform protection. But there is less flexibility. In an industry code-based DRM, voluntary codes raise coverage and awareness, but may lack in compliance. And hybrid models as argued before, they usually balance flexibility and trust. In the various parties involved. So, what is the conclusion? Uh, successful dispute resolution mechanisms depend on clear liability regimes. Collaboration between regulations and industry and consumer-centric dispute handling. Robust DRMs. When I mention robust, I'm referring to standardized legally sound. Uh, details, etc. These are essential to protect consumers and maintain trust in fast payments. Although fast payments are irrevocable, Still, refunds or returns can be structured. Under DRM frameworks. BRMs should keep on evolving as fast as fast payments mature from general guidelines into formalized and actually more comprehensive mechanisms and finally, but very important, fraud prevention strategies are also a key element of every robust DRA. So, That's it for, for me for now, Colin. Let me. That was, that was wonderful. Thank you so much though. That hit it right on the, right on the nose. If you didn't just walk us through, you know, what to think through, but how, you know, some of this combination of legal and different scheme levels and thinking through buy-in and coverage, but also, you know, commitment and making sure people are on board and prices and how to really operationalize this. Long term as well as thinking, you know, flexibly about, about DRM, uh, as well as just like the clarity. And this gets back to some of the key points about launching and scaling fast payment systems, about building trust and interoperability has incredible benefits, but as, as long as we do it correctly, uh, and, and with that kind of consumer user focused brain. Uh, and which is why DRMs are so important. So with that, thank you so much. Thank you to our audience, and we will see you all next time. OK. Thank you again very much. Thank you to everyone, and it's been a pleasure. Thanks everyone. Bye bye. Goodbye.
showAllTranscripts
no
duration
PT41M38S
scene7File
worldbank/Dispute-Resolution-Webinar-Jose-Antonio-20260128-180403
scene7Domain
https://worldbank.scene7.com/
scene7FileAvs
worldbank/Dispute-Resolution-Webinar-Jose-Antonio-20260128-180403-AVS
title
Dispute-Resolution-Webinar-Jose-Antonio-20260128-180403
description
Dispute-Resolution-Webinar-Jose-Antonio-20260128-180403
showTimestampAndTranscript
yes
col-xs-12
col-sm-12
col-md-3
col-lg-3
col-xs-12
col-sm-12
col-md-7
col-lg-7
  • 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 what happens when something goes wrong? Who is responsible when a payment is made in error, and how is that responsibility scaled across an entire jurisdiction of payments activity?

In this webinar, Colin Colter (Payments Consultant, World Bank) and José Antonio García García Luna (Senior Payments Consultant, World Bank) discuss the importance and nuances of dispute resolution mechanisms (DRM) in fast payment systems, how they build trust and help settle inter-participant conflict, and various jurisdiction case studies of how they can work in the real world.

lp-heading-top-medium
lp-heading-bottom-medium
col-xs-12
col-sm-12
col-md-2
col-lg-2