Publicly Discoverable ePayment Address(es)

From IDESG Wiki
Jump to navigation Jump to search

Publicly Discoverable ePayment Address(es) Part 1, ENROLLMENT:


Use Case Description: ENROLLMENT This use case should be considered as a work-in-progress, and must still be evaluated within the financial services community for issues such as liability, regulatory concerns, privacy, and business value. This use case is being posted to the wiki to obtain greater exposure within the IDESG community, and to encourage comments from the community regarding technical, standards, privacy, and usability issues that appear to be relevant.

Overview: In the face of mounting market shifts, new technologies, and regulations, financial institutions must look to new revenue sources. The growth in e-commerce, mobile commerce, and alternative providers adds urgency to that search. An important opportunity, that leverages the considerable FI investment in KYC infrastructure, is the establishment of a “neutrally positioned registry” of payment addresses. Known as the Greenlist® , it is an enabling technology for Immediate funds transfer and, on a larger scale, secure value exchange to support transactions in what is an increasingly internet-dominated global economy.

Description: Part 1 - ENROLLMENT. Minimal API consisting of a secureXML interface that is split into two separate interfaces: Registration (Enrollment) and Query. Via a person’s financial institution, obtain and register an ePayment Address to a financial account at said institution that is rendered safe to be publicly discoverable by masking account numbers with routable identifiers that can only receive deposits. Aligned with Fair Information Practice Principles (FIPPs) of data minimization & use limitation principles, ‘live’ bank account information never leaves the bank. The registry is the trusted custodian of benign debit-blocked payment address identifiers.

Purpose: To employ simple design characteristics that can be implemented without delay to a.) enhance safety and security by minimizing the ability for illegitimate (fabricated or stolen) identities to acquire identifiers with attributes having sufficient trust to utilize instant or next-day (monetary and/or high value information) asset transfer services; b.) enhance privacy by minimizing the risk that high-trust, private financial identifiers such as bank account or card numbers are unnecessarily divulged and therefore put at some risk to be improperly used to effect monetary or high value information asset transfer services without account-owner's authorization and c.) lay the groundwork for later extensions by Financial Institutions to enhance legitimate identities ability to assert ownership rights and privacy permissions pertaining to the use of cloud-based transactional data.

Specific Example so people understand how this Use Case is used by solutions providers and how their solutions benefit all critical stakeholders of the Identity Ecosystem May 21, 2013 Press Release

Implemented without delay means:

  • Little or no CAPEX required of Relying Parties or Identity Providers
  • Transactional Economic model means that each risk-bearing entity derives an economic benefit from every transaction (assumption is that every transaction is a discrete risk event) - NOT a subscription-based economic model
  • Applications utilizing an FI-centric Registry (attribute aggregation & trust assurance) Service can be compelling enough to justify introduction to consumers at targeted 'pilot scale' implementation levels.
  • Full optimal scale benefits can be realizable in a network effects business of this nature because of smooth, operational, regulator-compliant audit reports at every level of scale.
  • The fact that this solution has received Utility Patents in both the U.S. and China can be licensed to insure that consistent implementations of Greenlisting can be a neutrally positioned, uniformly administered resource in most every ePayment corridor.
  • This solution's value is compelling enough to maintain pressure for wide-scale adoption as central banks and regulatory bodies become aware of its potential impact.


Use Case Category: Trust/Assurance, Authentication, Interoperability, Privacy


Contributors : Richard O'Brien - Payment Pathways, Inc., Peter Tapling - Authentify, Inc., and Peter Gordon - FISGlobal & PayNet


Use Case Details

Actors: 1) Authoritative Parties – Operators of Registries containing Personally Identifying Information (PII) linked to publicly discoverable account identifiers supplied by an accredited registrar on behalf of registrants who have enrolled in highest level of privacy protection for financial account identifiers.

2) Financial institutions are accredited as Identity Attribute Providers upon their acceptance of liability for the binding of PII to ePayment Address(es). FIs trust and stand behind their own KYC process.

3) Relying Parties – Risk bearing institutions that transfer money on behalf of their clients/account-owners.

4) ePayment Networks – (or their assigns) provision account identifiers that mask or “tokenize” ePayment Addresses. This renders said ePayment addresses incapable of being automatically debited.


Goals: 1) Access trusted information to assure ePayment addresses of intended recipients of money transfers are true and mitigate risk of certain financial fraud attack vectors.

2) Fraud reduction which may imply cost reduction for the relying party.

3) Faster access to cash for money transfer recipients.

4) Viable business model for relying parties desiring to deliver instant non-repudiable money transfers.


Assumptions: 1) The relying party is a financial institution.

2) As the source and owner of the registrant data, the Identity Provider accepts legal liability for the accuracy of the registrant data.

3) The Authoritative Party is a custodian of the registrant data and is responsible for maintaining the accuracy and timely updating of data on behalf of all accredited Identity Providers.

4) Both the Authoritative Party and the Identity Providers share in transaction-based service fee revenue paid by relying parties.


Requirements: Internet access device, portal software, identity information for the authorizing user.


Process Flow: 1) User learns of an offer to obtain a safe publicly discoverable ePayment address from his FI.

2) FI obtains user’s permission to list sufficient personally identifying information to aid in the discovery of the user’s listing in the registry. This "opt-in" step may, at the discretion of the Financial Institution, include a voice-print .wav recording as a simple user-friendly "Captcha," and this file could be stored and available for later processing as a bio-metric authentication factor.

3) User selects a unique identifier that one can always remember when one wishes to receive an electronic payment from friends or strangers.

4) Registry affirms that requested unique identifier is indeed unique. If not, user re-submits the request.

5) FI obtains a "mask" for an RT/ACH bank account number (a.k.a.: "UPIC") and/or a debit card’s Personal Account Number (a.k.a.: “Tokenized PAN”).

6) FI registers one or both of the account number masks linked to the user’s unique identifier and PII.


Success Scenario: 1) Success, User is entered into database.

2) Relying Parties can access registered users’ information.

3) Relying Parties present PII to sender to verify that this is the intended recipient of the transaction.

4) Relying Parties trust ePayment Addresses as true and can now send transfers that cannot be repudiated for lack of sender authorization – which is completely in the control of the sender.

5) Recipient’s financial institution can post “good funds” directly to clients’ accounts instantly upon receipt of transaction message because settlement is always guaranteed.

6) Identities of International transaction participants reported to regulators per Dodd-Frank Section 1073


Error Conditions: 1) Failure, GLID is not unique.

2) Failure, Missing required parameter.

3) User’s PII not found – user wishes to be anonymous (note: no current mechanism to query user’s PII).

4) ePayment Address not found - user status: HOLD (note: no current mechanism to query ePayment address).


Relationships

Extended by:

  • Publicly Discoverable ePayment Address(es) Part 2 UPDATE & REVOCATION
  • Publicly Discoverable ePayment Address(es) Part 3 LOOKUPS

GRAPHIC 1: High Level Economic Model ePayment Address Registry

GRAPHIC 2: Greenlist in the NSTIC IDEcosystem

GRAPHIC 3: PayNet's Greenlist Benefits

GRAPHIC 4: Greenlist Benefits for Stakeholder Groups

GRAPHIC 5: PayNet Launch Schedule

References and Citations

  • Enhanced System for Electronic Funds Transfer and Elimination of the Payee’s Need for Encryption and Privacy

US Patent No. 7,831,490 Modigliani, O’Brien and Vitagliano claim a computer implemented method of conducting monetary asset transfer transactions associating a unique identifier with payment address that can only be debited by the accountholder. Such directories containing identifiers and payment addresses are synchronized to a root directory to enable non-repudiable deposits.

  • Methods and Systems for Identity Authentication

US Patent No. 7,945,511 O’Brien, Gallant, et al claim a computer implemented method of conducting informational asset transfer transactions where a registry of unique identifiers are associated with informational assets and access to said assets is regulated in accordance with guidelines established by communities of interest functioning as registrars.


Research Backing up Instant Payment Application built upon Lookup/Validation of a publicly discoverable ePayment Address