Re: Web Payments and Identity

On Tue, Sep 24, 2013, at 10:26 AM, Ricardo Varela wrote:

Firstly: do we have anybody from the banking industry on the list who
can further comment on this?


This is Madhu Nott, new member. I am from the banking industry, but
haven't commented so far because of my newness to the group.

Ricardo, I agree with the overall thrust of your argument: that the
requirements of financial identity are a bit more complex than "mere"
email based identities, which is the reason "banks don;t want a
mousetrap". Perhaps a better way of saying it is that financial
institutions and regulators perceive (correctly, I think) that the
demands of a secure financial system do and will require significantly
more strict identity verification than is possible via the current
generation of online identity technologies. The risks are seen to be
high.

Also, and this may seem like just a technicality, identity comes into
play not just during the KYC, or Know Your Customer, process, although
that is a crucial use case. FI's also need to establish identity (and
authority) in the course of routine and special customer transaction,
e.g., underwriting, payment authorization, address change.

Manu: Would it be useful to take an hour sometime to collectively
discuss the needs and desires of banks in the the web payments space?

Madhu Nott
The Payments Foundry
[1]mnott@paymentsfoundry.com

And then in the comments, you mention:
> Many of the banks that I spoke with would like to do KYC on their
customers once and then have some way of sharing the data (so they
don't
have to pay for the KYC process again when the customer goes to another
bank to get a loan, line of credit, etc.)

However, this is not the current case. Banks could do this now without
the need of any extra technologies, and they STILL don't do it anyway!
I don't think they need a better mousetrap, I think they just don't
want a mousetrap at all. It is one thing to make them work in a kind of
VISA or SEPA framework where there is certain uniformity, but they
still can use their own identities, and another one to try to put them
into using some "common" identity that they have to trust

Maybe having some browser-level "passport" of identities is more
feasible. However, I think is very unrealistic to continue thinking
that we can have a financial identity based on something like email.
Your email gives no info about your transaction behaviour and patterns,
how risky you are, how likely to become overdraft or be involved in
money laundering, etc... all information that a KYC process has got to
tackle

In operator billing we kind of get away with it because we can use the
user's mobile phone number, which is obviosuly linked to a subscriber
account on the operator side, and generally linked to a series of
personal data (in a prepay phone, from the form you had to fill) or
even an actual bank account (if you're a contract user) But still is
not very widespread as an identity mechanism (other than using the
phone number as part of 2-factor auth)

Saludos!

---
ricardo



On Tue, Sep 24, 2013 at 6:07 AM, Manu
Sporny <[2]msporny@digitalbazaar.com> wrote:

On 09/22/2013 05:32 PM, Ricardo Varela wrote:

Just for clarity, what use case exactly is that they "desperately

need" that online identity for?




It's specifically for the case where they would like to re-use Know
Your

Customer (KYC) data provided by other organizations, like the US

Government's assertions on Social Security numbers, for example.



Many of the banks that I spoke with would like to do KYC on their

customers once and then have some way of sharing the data (so they
don't

have to pay for the KYC process again when the customer goes to another

bank to get a loan, line of credit, etc.)




For the sake of background: I reckon the banks do not currently have

 widespread federated authentication schemes because it is up to

individual bank-to-bank agreements to trust the KYC of the other bank

 and they need rules about whose liability it is if the transaction

goes wrong.




Yes, this is true. However, they are paying a sizeable amount of money

with this approach because none of the data is shared (or rather, there

is no way to share the data between institutions). It's a pretty
classic

data portability issue. Many Web identity folks would like the
customers

to own this data and have control over who can get access to it. Banks

don't really care as long as they can get Know Your Customer (KYC)

assertions and they don't have to keep paying for the same data over
and

over and over again. Everyone would like this to be as simple as just

entering your email address.




By the way, to add to the mix: one of the comments in SEPA is that it

 makes sense that in some cases identity cannot be formulated in a

cross-border manner as there may be country-level regulations to add

to the EU ones (eg: data protection and retention policies in

Germany)




Yes, and this depends entirely on who is safeguarding the identity for

the customer. If it is a bank in Germany, then they fall under a

different set of rules and regulations as a bank in the US. That said,

these banks already have to deal with those headaches... nothing about

that changes with any of the technologies that are currently being

explored (Persona / PaySwarm).




So, back to the original bank question: are they proposing a specific

 scenario where the issue is actually technical?




There is a specific scenario where the issue is actually technical,
yes.

Namely, getting an assertion on an identity that includes a government

issued claim that the customer has a name, government issued ID number,

and digital signature on this information by the government that
asserts

that they are a real person.




or was this more the "visible excuse" for the reality that they have

other issues to solve before getting to that common solution because

a common identity still requires trust?




A common identity requires trust, and the banks will still have to
trust

a common set of partners, such as private institutions that have been

cleared by banks to do KYC along with governments with jurisdictional

authority over the banks.




PS: so that this is not just bank-bashing: I work with mobile

operators and the issues are more or less the same, more

legal/process than tech, and banks are even in a more advanced phase




There are legal/process issues at play here, but there are also

technical solutions that we can provide that would at least address the

technical side of the problem.



-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
[3]http://blog.meritora.com/launch/




--
Ricardo Varela -  [4]http://twitter.com/phobeo
"Though this be madness, yet there's method in 't"

Madhu Nott
The Payments Foundry
[5]mnott@paymentsfoundry.com

Madhu Nott
The Payments Foundry
[6]mnott@paymentsfoundry.com


ReplyReply to AllForward

[7]Compose
Save

Folders

References

1. mailto:mnott@paymentsfoundry.com
2. mailto:msporny@digitalbazaar.com
3. http://blog.meritora.com/launch/
4. http://twitter.com/phobeo
5. mailto:mnott@paymentsfoundry.com
6. mailto:mnott@paymentsfoundry.com
7. https://www.fastmail.fm/mail/compose?u=dc8c4127