Posted by Andre Edelbrock on Fri, Sep 10, 2010
|
|
| Facilitated collaboration, with formally structured protocols, makes legal and ethical data sharing possible. Doing it requires a system that makes sure all the participants can benefit from one another’s transaction experiences while not passing around the data itself. |
Last week, I participated in a roundtable session on ‘data sharing’ at the Merchant Risk Council’s inaugural European e-Commerce Payments and Risk Conference in Amsterdam. It was a great opportunity to exchange insights with other industry leaders from many countries.
Data sharing is great!
Imagine if there were no restrictions on what we could share to stop fraud. Walmart and Amazon would tell each other when they caught a fraudster, what email was used, his IP location, what was attempted to be purchased, when it happened, dollar value, name, credit card number, etc. No fraudster would ever succeed at stealing more than once or twice, and we'd have good enough pattern recognition and linked data that in many cases, we'd stop them before they tried to use a compromised card, account or data the first time.
That's the real promise and power of data sharing.
But Sharing Data? Yikes!
Unfortunately, we live in the real world, and companies don't just hand each other their customer and sales data. The reality is that sharing has its limits, and it's those limits that allow so much fraud to slip through our fingers. It's the fear of what the term 'data sharing' implies that often prevents us from doing anything at all.
In our discussions with merchants, card issuers, bank, payment processors, acquirers and the like we found that 'data sharing' implies informality and lack of structure, which immediately raises concerns about privacy, security, data integrity and trust. The term also raises legal concerns about what data, if any, can be shared. This is particularly true in Europe, which has stricter controls and regulations around privacy and varies by jurisdiction. Legal authorities and governments often assume that ‘data sharing’ means that account information is simply passed around between private parties with no regard for the individual's rights.
(For more on this see discussion in FinExtra about "unauthorized access" -- which is exactly the fear that sharing conjures up, and part of the reason that the Data Protection Act exists.)
When we collaborate, we can share experiences and knowledge without sharing the data
"What", you say?! That's some fancy verbal gymnastics. But, there is much truth that if we think about data sharing and the value it can provide differently, and expand the concept to one of collaboration where independent management, structure and governance are applied, we can escape the trap that everyone thinks data sharing is a great thing in theory, but few want to subscribe to it in practice.
Ethoca prefers the term 'facilitated collaboration', with a full set of formally structured protocols to make legal and ethical data pooling possible. It’s a system that makes sure all the participants can benefit from one another’s transaction experiences while not passing around the data itself. That means things like the strictest conformance to PCI across all PII, highly secured access, the management, auditing and certification of data integrity by independent authorities, access to information and anonymized experiences not the data itself.
Ethoca has already proved that facilitated collaboration can work on a large scale. Our strict protocols build trust among the participants. The merchants, issuers and other stakeholders know the data can't be mined for marketing purposes or accessed for any purpose other than fraud/risk management. The information is hashed and encrypted so that even Ethoca security experts can’t see personally identifying information. Participants also get large benefits, being able to leverage one another’s payment and fraud experiences and stop ecommerce fraud that they’d never catch otherwise.
So is the difference between ‘sharing’ and ‘collaboration’ only a matter of semantics? No. As my colleague Darryl Green wrote recently, collaborative fraud prevention is the future – and trust is the key.
We'd love to hear about your experiences with data sharing. Why has it worked or not worked for you? What value would you get from facilitated collaboration versus data sharing? Please share your feedback in the comments below.
Posted by Paul Paetz on Thu, Jun 10, 2010
Darryl Green is Chief Governance Officer (Co-Founder) and Executive Director at Ethoca
|
Beyond legal compliance: what it takes to be worthy of trust
I can’t stand privacy law.
Not for the reasons you might think are obvious for someone in my position (i.e. we can’t do what we want with impunity). I dislike it for what it represents and what it could, and in some cases appears to, be evolving into.
The fact is, I’m very much against doing what we want with impunity. At Ethoca, we are experts at fraud detection involving card-not-present transactions. We ask our partners, members and, ultimately, consumers to trust us with something very valuable (their credit card transaction data). We have a responsibility to earn that trust every single day. The concept of respecting and securing that data has to, and does, permeate every decision we make and every action we perform. The gravity of that trust lives in every employee of Ethoca and is deeply ingrained in the culture of our organization. Replacing these obligations with a regulatory compliance regime is both inefficient and distorting.
Taking responsibility
First, some brief background so you know my personal bias: I’ve studied law and worked briefly as a lawyer before finding the joy of entrepreneurship. I have, over the years, come to the conclusion that nearly all law can be summarized as, “Don’t be a dick.”
Of course, you need a little more granularity than that. If I ever ran for public office on a platform of legal simplification, I would suggest that there be laws against dickness in the first, second and third degree, and against unintentional dickness for those who have not thought about the consequences of their actions. Any more granular than that and you start to run into problems. (I may be exaggerating to make a point, but stay with me.)
Trying to create a regulatory regime to deal with an issue replaces, “I shouldn’t be a dick” with, “do I comply with regulations.” And since it’s impossible to draft regulations that contemplate all current contingencies, let alone contingencies arising from future innovation, it leaves individuals and corporations the ability to be dicks as long as they are regulatory compliant.
In fact, they may not even think about the consequences of their actions anymore, assuming that either the regulators will have contemplated the outcomes, or the outcomes don’t matter so long as I follow the rules. This is particularly problematic where those who work in the regulated industry are more informed and less conflicted than those drafting the regulation. There are examples of that all over the recent financial crisis, but that is not the subject of this discussion.
Now, back to Ethoca and privacy regulation:
In our first drafts of how we would develop the Ethoca architecture and operate the Ethoca service, we did not call legal counsel. We knew that caring for the data we were being entrusted with meant that we would have to respect it, secure it, and provide access to it in a way that wouldn’t allow it to be abused. We knew that we would have to watch over the data to ensure its quality. We knew that we would need a mechanism for members and consumers to dispute the data in the event of a misunderstanding.
We found codes of practice that helped us to define what that meant, specifically, the AICPA Privacy Framework, now called the AICPA Generally Accepted Privacy Principles. We engaged top-tier consultants to help us develop and implement the practices befitting the responsibility we expected to take on. In short, we took our responsibility extremely seriously. This was in part driven by our internal ethics, but was also required by anyone we wanted to add as members. We held ourselves accountable, and those we were doing business with were holding us accountable. Ah, if only the world could work this way in all contexts.
Enter the lawyers
The time came to get the regulatory analyses for the jurisdictions in which we contemplated doing business. These included most significantly the US, the UK, Ireland and Canada. This cost us hundreds of thousands of dollars in legal fees. (I wish I were exaggerating here to make a point.) I’m happy to say that it didn’t result in our having to change much of anything in relation to our operation. The work we had done just trying to be responsible took us well beyond what was required simply from a regulatory compliance standpoint. In a follow-up blog post I will summarize our findings from each jurisdiction and more detailed discussion is available from us for anyone contemplating joining Ethoca’s Global Fraud Alliance.
In general though, if you know nothing more than this about privacy law, as it relates to private enterprise, you are 90 percent of the way there: People have to be given the opportunity to agree to and know how their data is being used, they have to have the ability to inquire about and correct any mistakes in the data, and those holding the data have to safeguard the data with due care.
The final word
I’ve been a little glib here. Unfortunately, regulation is required where there is an imbalance of power as there is with respect to data. Consumers tend not to band together in a cohesive group, and the ability to abuse data that a company has been entrusted with would tempt some to make use of it for purely self-serving ends. However, the regulation should be minimal to meet the objectives highlighted above. In some jurisdictions I’m starting to see regulation that seems more like empire-building-through-bureaucracy than a regime meant to serve the needs of individuals. Clearly, any regulation that would make it unworkable or uneconomical to help consumers and merchants avoid being victimized by fraud would have slipped over that line.
Darryl Green is one of the co-founders in Ethoca. He has degrees in Law, Engineering and a Masters in Business Administration from the University of Western Ontario/Ivey School of Business. He started in the internet industry in 1999 with Tucows Inc. where he participated primarily in Business and Corporate Development activities. He worked there until co-founding Ethoca in 2005. Darryl is responsible for financial and regulatory compliance for Ethoca and, as with all the founders, is active in Ethoca’s Business Development. He tends to prefer free market solutions over government regulation and is big big fan of transparency and candor.
Posted by Andre Edelbrock on Mon, Nov 03, 2008
Red Flag Rules Delayed
Red Flag Rules apply to FIs and creditors with covered accounts (e.g., mortgage loans, automobile loans, credit cards). However, the broad language of the regulations has created enough uncertainty regarding their applicability to certain businesses to push the FTC to extend the compliance deadline to May 1, 2009.
Vague, Sweeping Language of Rule Leaves Many Uncertain
The unanswered question is whether it applies to oil companies, department stores, utilities, phone companies, all financial institutions of any size (from single branch community banks and credit unions on up), municipalities (water and sewage use contracts), waste management providers (many neighborhoods contract independently to have their garbage collected by their choice of company where residents sign individual contracts and hand over credit information to be approved for monthly billing), grocery stores, car dealers, appliance stores (6 months no interest layaway plans) — basically anyone who offers card credit or monthly billing or lease or store credit or a loan?
And as large a net as that casts, we wonder what about employers whose HR systems contain much of the same sensitive data. Will who has access to those systems come under scrutiny as well? And what about the ease with which those who aren’t “officially” allowed to see the data are able to view it? Any of these individuals could be singled out by identity thieves as targets for “social engineering” scams. Does that put their employer at risk for a creative ID theft lawsuit based on the regulation? — i.e. the one thing we know for sure is that the introduction of Red Flag Rules has created a sense there is open-ended risk of unknown size, with large costs for compliance and management (the same complaints that were thrown up when Sarbanes-Oxley was introduced).
Better Stewardship of Sensitive Personal Information
Regardless of the applicability of the Rules, what all these businesses have in common is that they maintain sensitive personal information that must be safeguarded. So even if you are small fry thinking the FTC isn’t targeting you, if it gets in the news that your company was part of the chain that lead to a stolen identity, you could be sued civilly and may be prosecuted legally, and you’ll lose in the court of public opinion, and in legal costs and long term reputation loss, which depending on the magnitude of the matter, could be business ending.
But back to the Rules…simply put the Rules focus on the holder of that sensitive personal information putting in place a program (and keeping it current) to ultimately prevent identity thieves from using peoples’ personally identifying information to open new accounts and misuse existing accounts. The program is to comprise three key components: identify, detect and respond to instances of identity theft.
Think like the criminal
Understand the Identity Thief
Arguably understanding the patterns of identity theft means you first need to start by thinking like the criminal. You know your data and your systems, and you should know where the vulnerabilities are. You have inside knowledge (note that most identity theft is suborned or supported by insiders), so if you were a criminal, what are the weakest points that you’d attack?
How would you the get names, SSNs, dates of birth, addresses and phone numbers stored in your systems? What social engineering techniques could you use i.e. who would you target and how would you ask for help in getting the data, and what makes him/her a likely candidate to either help directly or by being duped into helping?
What’s Your Potential Liability
Once you understand the vulnerabilities by which you can be compromised, build policies based on monitoring and disrupting the processes by which sensitive personal information can or might be accessed. Once you know how big your exposure is, you need to estimate the probability of a successful breach, and you should then allocate appropriate funds for compliance and dealing with potential losses.
And whether or not the Red Flag Rules are applicable to your company, you’d be wise to put in place a focused program to prevent and counteract identity theft…because it’s just as important for your company to avoid a loss at the hands of a stolen identity as it is for you to ensure your company is not the path to profit for identity thieves at the expense (loss) of the victim…one that may turn out to be a new or existing customer.
Related Articles