TOTAL: {[ getCartTotalCost() | currencyFilter ]} Update cart for total shopping_basket Checkout

Privacy Perspectives | An update on efforts to curb synthetic ID fraud Related reading: OCR issues rule for reproductive health care under HIPAA




It has been almost a year since I wrote about synthetic identity fraud and a then-new federal U.S. law intended to curb it. While a lot of work has been done since then, not much of it has made headlines.

A refresher: In May 2018, Congress enacted a law directing the U.S. Social Security Administration to build a system to connect with financial institutions that is capable of verifying in real time whether a given name, date of birth and Social Security number are a match with what the SSA has on file. Since SIF starts with a criminal attempting to use valid SSNs paired with other fabricated bits of personal information to create a new credit file, the idea is that by empowering financial institutions with a tool to make this validation when it receives an application for a credit product, this type of identity fraud can be stopped before it impacts consumers.

So, what has happened since then? For starters, awareness of SIF has skyrocketed, which is generally a good thing since it is considered the fastest-growing form of financial crime in the U.S. Recognizing that, the Federal Reserve published a paper highlighting the issue, and vendors of anti-fraud and digital identity services have ramped up their offerings and educational efforts significantly over the past year.

But even the most sophisticated, machine learning–driven tools available to financial institutions are still missing the answer to the key question that only the SSA can provide with authority: Does the given SSN match the number in the SSA’s database?

Which brings us to the work the Consumer First Coalition and other stakeholders are doing to get the law implemented and the real-time verification system built. Our partner in this effort is the SSA, which is probably not the first federal agency that comes to mind when thinking of bank regulation. Understandably, there has been quite a bit of education for both sides: Over the last year, stakeholders have engaged in an in-depth discussion regarding applicable laws (with a heavy focus on the Electronic Signatures in Global and National Commerce Act and the privacy and security aspects of the Gramm-Leach-Bliley Act), bank operations and the intensive supervision conducted by regulators.

As future customers of the SSA’s system (which has been dubbed the Electronic Consent-Based Verification System), our work with the SSA has not only included providing insights on financial regulation, but also addressing more practical questions. For example, what role could bank service providers (credit bureaus and others) play as intermediaries, channeling verification requests from bank clients to and from the SSA’s eCBSV database? And what would be the best way to capture consent — a statutory requirement — without causing consumer confusion during the application process?

On the technical side, these aspects of eCBSV development present an interesting dichotomy: The scale of the SSA’s core mission, dispensing hundreds of billions of dollars in benefits to many millions of Americans, dwarfs that of the eCBSV. Yet, eCBSV is in some ways just as challenging: Americans, as a whole, are homogeneous (in that they are people of the human variety). The SSA sending money to an individual American is fairly easy and can be accomplished predictably in well-defined ways (mail a check, direct deposit, etcetera). The financial industry, on the other hand, is remarkably complicated. It’s full of global banks, local credit unions and nonbank technology firms, to name a few. Some are hyper-technical and pushing into new areas of digital banking, while others are focused on the basics of banking: taking deposits and making loans. Payment networks run rails, and credit bureaus build profiles. Some have billions to invest in their own infrastructure, while others outsource most of their backend operations to service providers.

Technical considerations for eCBSV, including ensuring it can integrate across a large and diverse financial industry, aren’t as simple as “build an API, and they will come.” To meet Congressional expectations, which are focused on the SSA providing industry with a tool to help protect consumers from identity fraud, the iterative development process will need to address a long list of issues, including:

  • Defining service-level expectations to meet the demands of an always-on digital financial ecosystem.
  • Building the hardware infrastructure to accommodate potentially hundreds of millions of verification requests a year while minimizing downtime.
  • Maintaining the highest levels of data accuracy, integrity and security.
  • Authenticating that requests are from authorized entities that may or may not be utilizing a service provider as an intermediary.
  • Finding ways to incorporate fuzzy logic algorithmic matching to enhance and expand the value of the data the SSA sends back to users of the system.

Again, that’s just a sample of the technical issues. The list is long.

This summer, the SSA took a major step in the implementation process when it published a Federal Register Notice announcing an enrollment period for a two-phased eCBSV rollout in 2020. The notice includes details on project funding and offers something novel: It calls for the system to be paid for entirely by its users (the financial industry). Under the law, the SSA cannot begin building the system until it has collected at least 50% of the startup costs. In the announcement, the SSA described a series of volume-based tiers that will determine how much individual financial institutions — or service providers working with groups of financial institutions — will have to pay to get the system off the ground.

Looking ahead, because of the quirks of the law, the finances will need to be sorted out over the next few months before anything material can begin. From that point until mid-2020, the SSA will build a bare-bones “Minimum Viable Product” test with a small cadre of firms, then begin expanding and improving until full implementation is achieved.

For readers involved with private sector IT projects, this probably seems like a timeline moving at the speed of continental drift. But for a federal agency as expansive as the SSA that has had to engage with and learn the technical capabilities and expectations of a different customer base, the process is actually moving along quite well. The end result will prove an important tool for combating SIF and helping to enhance the identity verification process throughout the financial industry. It will be well worth the wait.

Photo by Austin Distel on Unsplash

Credits: 1

Submit for CPEs


If you want to comment on this post, you need to login.