Warning:
This wiki has been archived and is now read-only.
View source for StakeholderPriorities/BankOutreach

Jump to: navigation, search
You do not have permission to edit this page, for the following reason:
The action you have requested is limited to users in one of the groups: Users, 106, 73816-chairs.
You can view and copy the source of this page.
People involved in the bank stakeholder discussions to prepare for TPAC 2015 use this wiki in conjunction with outreach to different organizations.
== Instructions ==
* Use the [[#Email Template|Email Template]] below as a starting point for your outreach. Feel free to modify the template, but we suggest leaving the questions as-is to enable comparisons with other responses.
* Add an entry for each organization under "Feedback" with your name, the name of the organization, the date you spoke with them or received feedback (e.g., by email) and the feedback.
* Please try to gather feedback and update this wiki by '''29 September 2015'''.
== Outreach ==
=== European Banking Federation ===
Who: Ian Jacobs
=== French Banking Federation ===
Who: Ian Jacobs
=== European Savings Bank (ESBG) ===
Who: Ian Jacobs
=== Societe Generale ===
Who: Ian Jacobs. (Reached out 2015-09-17)
=== BNP ===
Who: Ian Jacobs. (Reached out 2015-09-17)
=== Cartes Bancaires ===
Who: Ian Jacobs. (Reached out 2015-09-17)
Response: CB is forwarding to PayLib for comment.

=== Bank of Japan ===
Who: Ian Jacobs. (Reached out 2015-09-17)
Response: As central bank (not retail bank), not well-positioned to provide answers, but suggested we forward to some other banks in Japan.

=== Rabobank ===
Who: Ian Jacobs (will ask Evert)
=== DNB ===
Who: Ian Jacobs (will ask Jurgen)
Reply: Jurgen will reach out to the Dutch Banking Association.
=== US Fed ===
Who: Ian Jacobs (will ask Pat and Claudia)
=== Wells Fargo ===
Update:
* Mark indicated that the time frame was challenging and recommended banking associations.

=== Citibank ===
Who: Ian Jacobs. (Reached out 2015-09-17)
=== Capitech ===
Who: Adrian Hope Bailie
=== Standard Bank ===
Who: Adrian Hope Bailie
=== FNB ===
Who: Adrian Hope Bailie
=== ABSA ===
Who: Adrian Hope Bailie
=== Nedbank ===
Who: Adrian Hope Bailie
=== National Bank of Ghana ===
Who: Manu Sporny
=== R3 ===
Who: Arie Levy Cohen
=== Santander ===
Who: Arie Levy Cohen
=== BBVA ===
Who: Arie Levy Cohen
=== Barclays ===
Who: Arie Levy Cohen
=== Morgan Stanley ===
Who: Arie Levy Cohen
=== ABN-AMRO ===
Who: Ian Jacobs. (Reached out 2015-09-17)
Evert: They indicated they won't be able to respond.

=== Capital One ===
Who: Ian Jacobs. (Reached out 2015-09-17)
=== Deutsche Bank ===
Who: Ian Jacobs. (Reached out 2015-09-17)
=== HSBC ===
Who: Ian Jacobs. (Reached out 2015-09-17)
=== Ted Bissell ===
Who: Ian Jacobs. (Reached out 2015-09-17)
=== NACHA ===
Who: Ian Jacobs. (Reached out 2015-09-17)
=== Camara Interbancaria de Pagamentos (CIP) ===
Who: Ian Jacobs (Ian will ask Leandro)
=== Mellon Bank ===
Who: Arie?
=== BITS ===
Who: Mark Tiggas
=== Clearing House ===
Who: Mark Tiggas
=== Focafet ===
Who: Ian Jacobs. (Reached out 2015-09-17)
=== Tokyo Mitsubishi UFJ Bank ===
Who: Sam Sugimoto
=== Sumitomo Mitsui === 
Who: Sam Sugimoto
=== Dwolla ===
* Ian wrote on 18 and pinged on 5 October.

=== Other suggestions ===
* Independent Community Bankers of America, ICBA
* American Bankers Association

== Email Template ==
<pre>
Dear XYZ,

As you may know, the World Wide Web Consortium (W3C) Web Payments Interest Group [1]
seeks to make Web payments easier and more secure, primarily through open standards. 
Through its membership and ongoing engagement with industry, the group identifies 
stakeholder priorities and standardization opportunities. 

The Interest Group proposed an initial standardization scope to the W3C Membership
in August, and that standards group is expected to start by November 2015. 

To identify the next set of priorities for the Web, the Interest Group is building
an agenda from updated industry input. As a representative of the group, I'd like to
enlist your help and invite you answer the questions below (some or all of them as
you prefer).

At our face-to-face meeting in October we will review feedback. After that meeting
I will follow up with you to share the outcome of our discussions.

If you are available, I would like to walk through the questions with you interactively
and take notes on the discussion. However, if you prefer, we can work together by email.

I would be happy to answer any other questions about the status of the W3C
payments activities. If your organization would like to contribute directly to the
development of Web technology at W3C and are not already doing so, please let me know.

For scheduling reasons, a reply would be appreciated by 29 September.

Thank you,

YOURNAME

[1] http://www.w3.org/Payments/IG/

=====================
Questions

Note: We have formulated these questions with retail customers in mind. However, if you prefer to
send feedback regarding other banking relationships, feel free to do so.

1. What is the most important service you would like to provide your retail customers but 
   cannot yet do so because of a technology obstacle? What are the reasons (e.g., lack of 
   interoperability, cost of deployment to multiple devices, lack of standards, 
   lack of adequate security, etc.)?
2. Would your customers value being able to make payments in conjunction with mobile banking 
   (e.g., through digital wallets or other banking applications)?
3. What other mobile payments use cases are you working on and when do you plan to deploy solutions?
4. What non-mobile Web payments use cases are you working on and when do you plan to deploy solutions?
5. What Web technologies do you already use in your retail banking applications? (e.g., OAUTH2).
6. What are the primary obstacles today that prevent you from deploying “credit transfer” 
   (push) payment schemes?
7. If you are involved in faster payment initiatives, are there new Web technologies that 
   you believe are important to success?
8. In your region, if there are open API regulatory requirements, are there new Web technologies that 
   you believe are important to success?
9. What issues (technical, legal, developer, etc.) lead you to choose native mobile platforms 
   over Web applications? Are there specific Web capabilities whose absence is limiting 
   delivery of services?
10. Would you like to see a "four-corner trust model" more readily available (natively) on the Web?  
   If so, what new capabilities would the Web require?
</pre>

(Other questions that might be useful):

* Will your customers who are now able to initiate payments from their bank accounts through their mobile phone also use these services for e-commerce?

== Feedback ==
The following is a synopsis of feedback received. 
=== Responses to questions ===
==== Most important service and obstacles ====

 What is the most important service you would like to provide your retail customers but 
 cannot yet do so because of a technology obstacle? What are the reasons (e.g., lack of 
 interoperability, cost of deployment to multiple devices, lack of standards, 
 lack of adequate security, etc.)?

* Instant payments because of interoperability. 
* Seamless shopping experience based on trusted payment relationship
* Universal wallet due to proprietary technology (i.e. apple)
** Currently, the process of providing mobile wallet solutions is very complex due to a great number of platform differences, security approaches and lack of functional standardization (definition of wallet capabilities)
* Basically, there is no technological obstacle which can’t be addressed. Move to ip-connected terminal has changed connectivity and bandwidth problems.
* Strong user authentication (heard from several banks)
* Onboarding new clients
* Lack of standards
** Around KYC, BSA and AML cross FIs. Companies Like LexisNexis have become the defacto standard for CPI verification for individuals and businesses. 
** Validation of accounts at a financial institution remains very difficult. Some services only add more complexity, costs etc for users. Companies and users need this and the workaround adds more  vulnerabilities. Users are not aware who stores the bank account credentials and what information is being cached. FIs could find an simpler and more secure way to validate accounts.
* Security
** End to end security standards and requirements are  subject to interpretation.  Tokenization is implemented in different ways leading to more confusion. 
** Settlement and Clearing: What can/should/can not/should not be done by technologies like BlockChain.
** Lack of sharing: EcoSystem can be safer if breach and fraud information is shared between all participants. 
* Most important value-added services (one company's perspective)
** CIP for Customer, Send, Request, Schedule payments for multiple currencies, provide a real time money movement. 
** Platform consists of the following core components - Directory, Ledger and Settlement
** Innovation in payments would come from an ecosystem of application developers when they develop features around loyalty, savings, peer to peer lending, micro payments etc.
* Another company: "We want to give our customers simple and secure access to all their banking / payments / money management needs when and where they like. Impediments include security needs; regulatory constraints and complexities across multiple markets; technical complexities across devices, operating systems, browser types & versions, POS systems, etc.; and lack of ‘common standards’ across all."
* Another company: "Seamless shopping experience based on trusted payment relationship. Currently, the process of providing mobile wallet solutions is very complex due to a great number of platform differences, security approaches and lack of functional standardization (definition of wallet capabilities)."
* Another bank: "Seamless check out (whether with or without wallet) Please take partially note of the outcome off the ERPB working group on contactless (mobile) payments"

==== Mobile payments with banking ====
 Would your customers value being able to make payments in conjunction with mobile banking 
 (e.g., through digital wallets or other banking applications)?

* Yes. It is important to differentiate banking services from payments. Non-financial third parties are already establishing this difference.
* Users value them. One person replied that there were complaints when the mobile app was implemented without payments.
* "Yes, even in solutions provided by new entrants"
* One bank indicated that lack of a "universal menu" (in HTML5) is an obstacle.
* Deployment of Wallets is a priority and interoperability to enable change of wallet provider but keep transaction history
* One response: "Yes – we are continually exploring ways to utilize the security and trust of our consumer banking relationships to optimize digital and non-digital experiences."
* One response: "Yes, deployment of wallets is a priority for us."
* One bank: "The questions of integration of applications is not answered yet. Customer experience has to give us this wisdom"

==== Other mobile payments use cases ====
 What other mobile payments use cases are you working on and when do you plan to deploy solutions?

* Contactless payments
* One company responded they provide a full SAAS-based platform
* Mobile banking including development of instant payments (credit transfers)
* Proximity payments (card emulation with EMV/NFC)
* Loyalty (MyOrder wallet)
* One response: "We launched Apple Pay to our (region) credit and debit card customer base and are continuing to look at enabling digital wallets in our key global markets. We are building-out a variety of value-added services and are very interested in converging these solutions with online / ecommerce payments."
* One bank: "P2P, HCE, Wallet, see also ERPB working groups (also the P2P)"

==== Other non-mobile payments use cases ====
 What non-mobile Web payments use cases are you working on and when do you plan to deploy solutions?

* With responsive design technologies, this is no more an issue.
* Institutional money 
* One response: "We are interested in ideally leveraging existing tokenization and digital enablement work to make online/ecommerce payments simple and secure for our customers: ideally showcasing the bank card brand during the process. We believe that value-added services are key to a compelling customer and merchant proposition."
* One response:
** Tablet based POS payments 
** Bank credentials in the payment flow
** Payment request 
** Instant payments (credit transfers)

==== Technologies used today ====
 What Web technologies do you already use in your retail banking applications? (e.g., OAUTH2).

* One company's response:
** Authentication and Authorization: Use MFA and OAuth with fine grained scopes
** Encryption: Strong end to end encryption, Strong TLS 
** Statistical models for anomaly and fraud detection
** HTML 5 for UI
** Auto Scaling and Micro Services 
** Backend: Big Data, Asynchronous protocols like Finagle and Thrift
* One response: 
** Multiple authentication mechanisms, up to 2 factor authentication / 3D Secure
* One response:
** I do not think the processing of transactional volumes will move to “the cloud” as the processing of payments is an important factor for the economy (systemic risk) and as such is regulated by the central banks. Banks may outsource processing when strong SLA requirements can be met, but I am not sure whether that would be influenced under the scope of the Web Payments Interest Group’s work.
* One response:
** Html5, Javascript, JSON, Apache Cordova. We do have some OAuth capabilities, looking to expand in the future. We use SAML for authentication and authorisation in some scenarios.

==== Obstacles to push payments ====
 What are the primary obstacles today that prevent you from deploying “credit transfer” 
 (push) payment schemes?

* Batch processing in ACHs. 
* Profitability
* Lack of global interoperability agreements.
* One bank indicated that they support credit transfer for corporate payments. But "it depends on customer needs" whether they would offer it for retail payments.
* Lack of universal permissioned directory for identity verification
* Further “push” applications will be developed with Instant Payments (4 year project)
* One response: "We’ve yet to see a compelling customer proposition in this area that makes economic sense for the bank. As banks typically take all the risk in payments (and thus bear the brunt of the costs), this has been a challenging space."
* One response: "The iDEAL payment scheme is popular in the Netherlands which uses credit transfers but these are initiated via a retailer pull protocol. Further “push” applications will be developed with Instant Payments (4 year project)"]
* One bank: "Solutions need to work in the interbank space"

==== Faster payments needs ====
 If you are involved in faster payment initiatives, are there new Web technologies that 
 you believe are important to success?


* In Japan; depends on hours of national payment system (see below).
* "We don’t need new technologies to solve existing problems. We probably need more standardization on the above items."
* For the support of related API services, secure authentication mechanisms which can be used in a seamless buying and payment experience are required. Oauth2 is an example.
* One response: "For the support of related API services, secure authentication mechanisms which can be used in a seamless buying and payment experience are required. Oauth2 is an example."
* One response: "We work with the UK Payments Council on their Faster Payments system. FP provides the underpinnnings to a p2p payment functionality available in our mobile app."
* One bank: "For sure there is investigation necessary (blockchain etc)"

==== Open API requirements ====
 In your region, if there are open API regulatory requirements, are there new Web technologies that 
 you believe are important to success?

* Japan. Currently, open API has not been a regulatory issue – financial institutions are more cautious to introduce them for security reasons.  And now some of the banks started to use cloud solutions for their banking operation and regulatory authorities have started to set new guidelines for using cloud environment for mission critical operations.  Anticipate an expansion in bank APIs once regulatory guidelines for cloud solutions are established.
* One company's response:
** Authentication and Authorization into a universal permissioned directory
** Standards around user verification with financial institutions and card providers
** Tokenization and Standards for securing it, validating it and resetting it
** Clear definitions and standards around clearing, settlements, authorization of payments etc
* For one institution it was not clear yet.
** Within the SEPA region, the Payment Services Directive 2 requires strong authentication for web payments, and an open market for payment initiation and account information services.
** The API design is still to be determined (look at the DCSI initiative, for instance).
** Message data fields will be derived from ISO 20022 definitions (realtime payments), but will have to be formatted in an API-friendly way.
* One response: "Not clear yet. Within the SEPA region, the Payment Services Directive 2 requires strong authentication for web payments, and an open market for payment initiation and account information services. The API design is still to be determined (look at the DCSI initiative, for instance). Message data fields will be derived from ISO 20022 definitions (realtime payments), but will have to be formatted in an API-friendly way."
* One response: We are not aware of any such regulatory requirement in APAC, but seems that in Europe it's really coming (PSD2). Regarding API, we believe in the importance of having an API management system: a standard way for the bank to expose services to 3rd party API, make these services discoverable, and manage credentials issuance and revokation in a semi-automated way.

==== Factors that affect choice of platform ====

 What issues (technical, legal, developer, etc.) lead you to choose native mobile platforms 
 over Web applications? Are there specific Web capabilities whose absence is limiting 
 delivery of services?

* Potential lack of mobile signal. 
* Better speed and user experience
* Currently, web security (phishing attacks and malware) are major concern to our customers.
* With HTML5, i don’t see. The question is more on public equipment able to work with up to date technologies.
* Security, especially as services gradually migrate to the cloud. Also, regulators will need to bless security approaches.
* Extracted Response:
** We currently use different strategies for Mobile Banking and the payment wallet.
** Our Mobile Banking platform is hybrid with native and web technology. This results in a flexible and maintainable design, but requires special attention on performance and UX consistency.
** The payment wallet is based on Apache Cordova and has an elaborate widget infrastructure to combine different functionalities such as NFC payments and loyalty application.
** Development of the payment wallet is difficult to support multiple security platforms (eSE, SIM, HCE) and device software and hardware variations.
* One response:
** We currently use different strategies for Mobile Banking and the payment wallet. Our Mobile Banking platform is hybrid with native and web technology. This results in a flexible and maintainable design, but requires special attention on performance and UX consistency.
** The payment wallet is based on Apache Cordova and has an elaborate widget infrastructure to combine different functionalities such as NFC payments and loyalty application. Development of the payment wallet is difficult to support multiple security platforms (eSE, SIM, HCE) and device software and hardware variations.
* One response:
** We did not choose native platforms. Our app is hybrid, i.e. a web app packaged into a native container to have access to some native capabilities.
Considerations that influence this choice - that we are constantly re-evaluating - are:
*** business usually provide solutions (e.g. "native app") as opposed to requirements (e.g. smooth animation, scrolling and full screen, hw accelerated transitions"). The requirement can be fulfilled by web technologies, too.
*** lack of developer's skills (better: lack of developer skills capable of building an advanced hybrid experience)
*** simplicity of execution in native overcome the supposed advantages of web platforms (portability, interoperability, resilience to "aging") 
*** using native gives us consistent and timely access to native capabilities, particularly newer features like TouchID

==== Four-corner ====
 Would you like to see a "four-corner trust model" more readily available (natively) on the Web?  
 If so, what new capabilities would the Web require?

* I am not sure that this technology is necessarily better than other to solve the interoperability problem.
* One bank cited experience with Identrus that did not succeed, partly because there was not a proper use case. Cost was an issue. The respondent indicated that a simple interface was necessary for various users to take part in the program.
* The web would require a method of sharing specific credentials as a business service from credential providers to credential users.
* One response:
** Not by this name, but we have been looking at the implications of a multi-app model and how do we establish trust between 2 of our apps. A robust and standard (aka: "widely supported") web capability in this space may influence our development toward web technologies rather than native ones.

=== Regional Notes ===
==== France ====

* Regarding after payments initiatives; any barriers?
** Not at the moment
* Regarding API regulatory requirements
** There is no regulatory API for the moment. All depends on what will emerge from PSD2.
==== Japan ====
* Mobile 
** Carrier billing the norm for small purchases
** Mobile wallets widely used for contactless payments and ticketing
* Cash
** Some e-commerce settlement currently takes place by paying in cash at a ubiquitous convenience store to receive a confirmation code or transmission of funds directly to the merchant
* Settlement
** Bank to bank transfers are prominent among consumers and can be initiated from ATMs and often online/mobile banking, however settlement is up to next-day
** One respondent wrote "Currently, our real time payment capability is limited to 9:00 – 15:30 (next day credit after Hours), due to the national payment system, “Zengin” operation hours.  Now Bankers Association of Japan has decided to expand operation hours, we would be able to expand our real time payment capability."
* Payment networks
** A multiplicity of non-interconnected networks service the contactless and prepaid cards space.
* Regulatory environment
** Regulator-mandated documentation requirements hold back a lot of services that could be launched through electronic channels.
* Technologies used:
** C-html, ALP, TLP, any i-mode or other MNO-proprietary security layer
==== Other topics ====
* Because of their strong KYC/AML practices, banks may have a business opportunity to act as identity providers.
== Narrative ==
The priority use cases I have heard (officially and unofficially) have centered surrounding the idea of settlements, treasury function across multiple time zones, cash management and associated exposure to FX risk and ultimately having the money in the right place on time, inexpensively (time and cost).

These seem to mostly revolve around institutional frameworks, albeit they center around servicing the needs of the bank's clients.

Whether a Bank is looking at Legal Entity Identifiers (LEI) [more on the institutional side] or Personally Identifiable Information (PII) [more on the retail side], there is a concern and interest across the board about database integrity and security. Protection against breaches, strengthening vulnerabilities, and protecting sensitive data has become increasingly important. These however are seen as internal concerns not relevant to the Web (as much) since most institutions are responsible for their own systems and few at present rely meaningfully on cloud based systems.

Whilst this may be an important insight, the question is whether financial institutions are inclined to migrate to the cloud at all. If they are not, we are not likely to have an impact. But if they want to and there are technology obstacles, we still must learn what those are. Also, it may be that PSD2 or other initiatives force them to move to more open networks.

With that said, I have been picking up a consensus that large cloud farms have surpassed Financial Institutions in terms of hardware purchases and telephone company contract size: "could farms are becoming cheaper, faster and stronger by the quarter, but are they secure". What one high level insider shared was that the forward path was to over time move much of the bank's high volume traffic over to the cloud (eventually) leaving the more core functionalities inside, again, with security being the "door".

A caveat comment to the bove is taken from a conversation I had with a divergent view: "I do not think the processing of transactional volumes will move to “the cloud” as the processing of payments is an important factor for the economy (systemic risk) and as such is regulated by the central banks. Banks may outsource processing when strong SLA requirements can be met, but I am not sure whether that would be influenced under the scope of the Web Payments Interest Group’s work. The W3C work is important for the development of the user interaction. Many retail banks however do not see the relevance of the work (yet) which might be caused that user interaction is developed by and with technology partners such as wallet providers, e-commerce checkout services, card schemes, and so on."

I have seen conversations engage more meaningfully when institutions see they can leverage established systems where incorporating interoperable modifications and/or upgrades can accomplish these improvements (platform changes are not of clear and present interest but are being explored).

One shared critical pain point for all institutions on both the retail and institutional side resides is their acute need to maintain the highest level of adherence to AML, KYC, Legal & Compliance to meet each of the respective regulatory rules and regulations (Finra, FinCEn, SEC etc...). On the retail side, this falls squarely on the lap of security and identity (Credentials/LEI) and it impacts client on-boarding (account opening), wire transfers: the overall UX and the institutions cost to remain compliant.

A big question remains: what could we (W3C) actually do to help lower those costs? If, in practice, to satisfy on-boarding requirements a lot of in-person non-digitized interactions are required, then it’s not clear what we can do. So, what will banks accept (from a regulatory perspective) in digital form that is not already done today? 

This Appendix below by Evert Fekkes supports some of the thoughts shared above;

Although I have forwarded the questionnaire to the Dutch Payments Association and their respective working groups, this has not resulted in answers from any other banks.

This leads me to the conclusion that most banks do not yet see W3C efforts as a direct requirement for the development of web payments.

Much work is being done in the Netherlands, as the Payments Association is developing "Payments 2.0" functions such as the Payment Request and Bank Identification service based on the iDEAL infrastructure. Next to that, an important program is "Instant Payments" which aims to create a new faster payment infrastructure within 4 years.

I think that more clarity is required on the approach to API development to meet the PSD2 requirements in the near future.

The European Banking Authority has published several documents on the subject:

* [https://www.abe-eba.eu/downloads/knowledge-and-research/20150511_EBA_Opinion_Paper_on_exploring_the_DCS_v1_0.pdf Opinion Paper on exploring the Digital Customer Services Interface] .European Banking Federation put that out recently, overlapping with what we're doing at W3C. It's worthwhile looking into if we can refer to it in the scope of our work.
* [https://www.abe-eba.eu/downloads/knowledge-and-research/EBA_20150511_EBA_Cryptotechnologies_a_major_IT_innovation_v1_0.pdf Cryptotechnologies, a major IT innovation and catalyst for change] (on cryptocurrencies)
Return to StakeholderPriorities/BankOutreach.
Retrieved from "https://www.w3.org/WebCommerce/IG/wiki/StakeholderPriorities/BankOutreach"
View source for StakeholderPriorities/BankOutreach

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Navigation

Tools
