Regulatory Landscape TF

Activities since previous meeting

jyrossi: since the previous meeting I reached out to people about joining the task force.
... we face a challenge of bringing together regulatory people and developers....they speak different languages
... it would help to have a regular meeting (e.g., 30 minutes) to bring new contributors to the group.

william: I would like to understand the methodology proposed by jyrossi...
... should we approach this from a business model perspective?
... and see which regulations apply (e.g., DPS in Europe)
... it would be interesting to see what is at stake and the potential impact, knowing today that if we look at the card payment business we take the same approach ...
... we have an acquirer to issuer model..and we look at the different relationships among actors, and where regulations affect them.
... could we do the same thing?
... could we look at some regulations in a few countries, and see what are the potential impact.
... e.g., we look at payment transfer...we look at how card schemes do it today, and we look at the impact on various actors
... so one potential way to do this evaluation is how actors interact, and what the business models are.
... and what would be the potential impact on that...most regulation looks for more transparency for customer...

jyrossi: my understanding of what we should do is to ensure that implementations of the specs will be as smooth as possible from a regulatory perspective.

<jyrossi> https://www.w3.org/Payments/IG/wiki/First_mapping_of_main_juridictions

jyrossi: for that reason, I think one of the first steps we need to take is to do a high-level mapping of jurisdictions
... it means understanding the regulatory constraints, where they are, and who could be the resources
... another question will be, in all these jurisdictions, what are the main questions we should consider
... in conversation with Evgeny, we concluded that the requirements would be similar in many jurisdictions.
... therefore i think we should consider main regulatory topics

<jyrossi> https://www.w3.org/Payments/IG/wiki/Main_regulatory_topics_about_payment_services

https://lists.w3.org/Archives/Public/public-webpayments-ig/2017Jan/0038.html

<jyrossi> Ian: Concerned that a merely "top down" approach could waste too much time. Wondering if an other approach could be more efficient, from the essence of the specs and asking experts and regulatory authorities from that feed backj

IJ: I think we should take an approach of capturing the essential of the specification in terms that regulators can digest. That will give us feedback that is directly relevant to the specification. Otherwise we may do a lot of work on topics unrelated to what we are actually doing

jyrossi: I think we need both. In order to attract regulatory experts to bring useful input, we really need to have what you mentioned.

(I feel that we should START from the spec)

jyrossi: We need to get interest from both sides.
... I do think that we need to do both
... in order to start, we need a methodology

(Ian is proposing one)

<Zakim> dezell, you wanted to give an analogy with ATICA, and speak to the effort required by the TF along with scope of the spec

dezell: I believe that jyrossi's suggestion would not require a lot of effort...I see this as less burdensome than Ian does.
... I think we have to be cognizant that what we do may be useful to the WG today but also may be useful later.
... quick cookbook for people to know what to look out for

william: For ATICA, if we had to do it again, instead of focusing on the actual spec and the details of the spec, we would have stepped back and looked at the functional / business model and how people interact
... I think there are two approaches: (1) business model first or (2) pictures of the regulation...but we need a methodology
... I think a lot of provisions in the regulation may not have any impact on what we are doing
... so we need to be smart enough to know what will relate to what we are doing
... I think there are pros and cons to both approaches

jyrossi: can we get materials from the WG that are more tailored to regulatory?

IJ:

1) The WG is not concerned by regulation

2) The WG will listen to input on the spec

IJ: For me the metric for success is "Change proposals to the spec"
... otherwise we are not as likely to have an impact
... I think the WG will not drive a deliverable but that's a good thing for this task force to do
... I am happy to help

dezell: I think a goal is to ease adoption by giving them something they can hang on to

(Ian wants to know what that looks like)

dezell: gathering information as jyrossi has suggested could be useful.

<Zakim> dezell, you wanted to agree with the concrete goal, and to elaborate.

jyrossi: Here's an example of the kind of impact that regulatory issues could have on what the WG is doing.
... it's just a few lines from article #8 of european regulation

<jyrossi> art 8 #6 of Reg 2015/751/EU Payment card schemes, issuers, acquirers, processing entities and other technical service providers shall not insert automatic mechanisms, software or devices on the payment instrument or at equipment applied at the point of sale which limit the choice of payment brand or payment application, or both, by the payer or the payee when using a co-badged payment instrument. Payees shall retain the option of installing automatic me[CUT]

<jyrossi> in the equipment used at the point of sale which make a priority selection of a particular payment brand or payment application but payees shall not prevent the payer from overriding such an automatic priority selection made by the payee in its equipment for the categories of cards or related payment instruments accepted by the payee.

jyrossi: This is practically connected to what we are doing with payment request
... to have a relevant mapping, the first work about mapping main topics (not most but main)
... that is something very practical
... It's not as much work as it appears. I share the opinion that if we have the right people in the task force, it won't be that challenging to come up with a shared vocabulary to come up with the main issues.
... then this group can bring useful input to the Wgt

<dezell> I agree with Ian's concrete recommendations to the specification, i.e. to provide feedback to the WG. I also think that filling in Jean-Yves's templates will be useful in providing that feedback. Equally importantly, that gathered information will be helpful in easing the adoption of the Web Payments (in general) work in the greater web community. So I think we need both efforts.

vkuntz: I think there are multiple dimensions of regulations that can come into the scope of web payments...in some cases you can't even initiate the payment if you are a us company and you have someone on the @@ list
... another example is that if you want to do business in russia, the contract has to be registered before you do payment
... this does not have an impact on the API, but on how you initiate payment
... I think we need to inventory not necessarily individual regulations, but types of regulations where developers have to pay attention when they implement the API.

jyrossi: Should we start from regulations or from the spec?

vkuntz: I would start with classifications of regulation..then look into which part of the classification might have an influence on the APIs
... then working from there and what has to be looked at from the perspective of the details of the regulations

<dezell> +1 to starting from both sides.

<Zakim> Ian, you wanted to talk about audience

IJ: Audience?

1) Working Group

2) People who are using the API

If we want to reach the WG, we need to be concrete in spec terms

<vkuntz> Impact of regulation on the use of the APIs will lead into concrete requirements toward the working group

IJ: I think we would take a different approach and have different deliverables if our goal is to reach users of the API

dezell: I think the WG should be our primary audience.
... I think that jyrossi's approach would help us reach both audiences

jyrossi: I think the WG is the first target and API users the second target
... the second point I want to mention is a suggestion...it's about the question of where we start
... bottom up or top down
... vkuntz and I suggested that it will be useful to gather basic information from at least 3 jurisdictions
... I think we could do that in 2 weeks
... Ian, could you pick up three main items on which to focus from the regulatory point of view for the WG
... one could be "choice of payment instrument"

<jyrossi> "payees shall not prevent the payer from overriding such an automatic priority selection made by the payee in its equipment for the categories of cards or related payment instruments accepted by the payee."

IJ: I can work with concrete text and try to evaluate in terms of the spec

(I have been pushing back on abstractions)

vkuntz: I agree that we need to address the WG in concrete terms and how the spec would be impelmented
... another example, in most regulations there's a regulatory reporting aspect.
... normally it's on the payment provider's side
... for the WG there might be a consideration that they keep in mind..that there is regulatory reporting

IJ: I think a lot of the relationships among actors are the same...but some are slightly different it's true. That is why taking the bottom up approach and thinking in terms of what the spec does concretely will help us narrow the scope of the exercise

<Zakim> dezell, you wanted to say that I don't think there's any argument against doing what Ian is suggesting.

IJ: Let's be concrete first
... learn from our experience...whether from the regulatory side or the technical side
... I am hearing today:

1) WG is primary audience, users of API secondary

2) Let's be concrete

<jyrossi> JYR: let's be concrete on both sides!

+1 to being concrete

(IJ suggests we update the wiki with consensus points)

next call

IJ: I can no longer make Mondays at 9am ET

(I could meet at 11am ET on Mondays)

I could meet Thursdays at 9am ET

jyrossi: 11am ET is too late for Asia
... Proposed Thursdays starting 9 February at 9am ET

(IJ: some people can meet earlier, feel free!)

<vkuntz> 9 Feb ok for me - cannot be present on 30 January

IJ: If we were to model payment request API in terms of actors relating, would that help regulatory folks narrow scope of their owrk?

<jyrossi> * Tx Vincent!

william: We need to work on an exchang emodel
... at first glance, it does not seem to me that looking at the API will tell us all the sceanrios
... we should be speaking about business case

<jyrossi> Next meeting Feb 9, at 9 am ?

<scribe> ACTION: william and Ian to experiment with a business model approach to formulating what the API does in terms that could help narrow or focus the regulatory evaluation [recorded in http://www.w3.org/2017/01/23-wpay-reg-minutes.html#action01]

William: In general, Thursdays won't work for me

Next meeting: 9 February at 9am ET

<scribe> ACTION: Ian to send out a webex for 9 Feb meeting [recorded in http://www.w3.org/2017/01/23-wpay-reg-minutes.html#action02]

IJ: I suggest updating the wiki to talk about audiences (in priority order)
... activities that we think are necessary to achieve goals
... and clarify the goals

- ensure the API of the WPWG does not inherently raise regulatory issues

- help users of the API understand regulatory considerations around the initiation of payments

jyrossi: requirements more than considerations