Join 4,000+ Subscribers

Get tips & tricks to optimize your ID verification flow

BlogGet Started

How to Write Better Code Using Mutation Testing

By John Backus on October 29, 2015

Abstract syntax tree

When developers talk about “test coverage” they are typically talking about how many lines of code are executed by their test suite. This is a simple calculation: what percentage of our code was run by our tests? We don’t want to accidentally break our code later so having strong test coverage is important.

Mutation testing is not an alternative to line coverage. While line coverage asks “what percentage of our code is run by our tests,” mutation testing asks “what code can I change without breaking your tests?” Mutation testing tools answer this question by applying and testing small modifications to your application.

This post explores how asking “what changes don’t break my tests?” can benefit more than just test coverage. Using a ruby mutation testing tool called mutest, I’ll introduce and reflect on two separate code examples to demonstrate how mutation testing helps you improve both your tests and your code itself.

Mutest keeps your tests honest

Consider this script for looking up users who tweeted ‘“I really enjoy #pizza”’:

require 'twitter'

class Tweeters
  def recent
    query.first(3).map do |tweet|
      "@#{tweet.user.screen_name}"
    end
  end

  private

  def query
    api_client.search('"I really enjoy #pizza"')
  end

  def api_client
    Twitter::REST::Client.new do |config|
      config.consumer_key        = ENV['TWITTER_CONSUMER_KEY']
      config.consumer_secret     = ENV['TWITTER_CONSUMER_SECRET']
      config.access_token        = ENV['TWITTER_ACCESS_TOKEN']
      config.access_token_secret = ENV['TWITTER_ACCESS_TOKEN_SECRET']
    end
  end
end

puts Tweeters.new.recent if __FILE__ == $0

To illustrate the difference between “line coverage” and “mutation coverage” consider this intentionally bad test:

require 'simplecov'
SimpleCov.start

require 'tweeters'
require 'rspec'

RSpec.describe Tweeters do
  it 'returns results' do
    expect(Tweeters.new.recent).to_not be(nil)
  end
end

Now if I run this test:

$ rspec -I. -rpizza_spec.rb
.

Finished in 0.94429 seconds (files took 1.38 seconds to load)
1 example, 0 failures

Coverage report generated for RSpec to /dev/coverage. 15 / 15 LOC (100.0%) covered.

My test passed with 100% coverage.

If I run this test again with mutest and instruct it to only mutate the recent instance method then I see the following summary:

Mutations:       36
Kills:           19
Coverage:        52.78%
See full output

This tells me that my recent method actually has 52.78% mutation coverage! This means that mutest found 36 ways it could change my method and only 19 of those changes resulted in my test failing.

Mutest shows me what my tests missed. For example, here are three of the nineteen mutations my tests did not catch:

 def recent
-  query.first(3).map do |tweet|
-    "@#{tweet.user.screen_name}"
-  end
+  self
 end

 def recent
   query.first(3).map do |tweet|
-    "@#{tweet.user.screen_name}"
+    nil
   end
 end

 def recent
   query.first(3).map do |tweet|
-    "@#{tweet.user.screen_name}"
+    "@#{tweet.user}"
   end
 end

Again, the test for this script was intentionally bad, but the difference in results is important. All my test did was assert that my recent method did not return null. This assertion did technically exercise 100% of the code though so the line coverage tool is reporting 100% coverage. Mutest quickly showed me that it could make my method return self, [nil, nil, nil], and ['@#<Twitter::User:0x1>', '@#<Twitter::User:0x2>', '@#<Twitter::User:0x3>'] without breaking my tests.

The takeaway here is not that line coverage is bad. You can write good tests without mutest. Instead, think of mutation testing as an x-ray for your tests. Running mutest on new code can help you double check that your tests are covering everything you care about. Mutest can also be a powerful tool when conducting a code review. It is easy to see roughly which methods are tested, but it can be hard to spot what that original author might have overlooked.

Mutest helps you write more robust code

Imagine you are tasked with creating an endpoint in your company’s internal API which does two tasks:

  • Looking up users by their unique id
  • Returning a list of users which signed up after a certain date

A few hours later you write the following code

class UsersController < ApplicationController
  # Looks up GET param `user_id` and returns user
  #
  # @return [User]
  #
  # @api public
  def show
    render json: UserFinder.call(params[:user_id].to_i)
  rescue UserFinder::RecordNotFound => error
    render json: { error: error.to_s }
  end

  # Finds users created after date specified in GET param `after`
  #
  # @return [Array<User>] list of users
  #
  # @api public
  def created_after
    after = Date.parse(params[:after])
    render json: UserFinder::Recent.call(after)
  end
end

Along with this code you write some unit tests for the different edge cases you expect your controller to handle:

$ rspec --format documentation users_controller_spec.rb

UsersController#show
  returns a user when given a valid id
  renders JSON error when given an invalid id

UsersController#created_after
  returns multiple users given an early date
  excludes users created before date and includes users after
  renders empty array when date is in the future

Finished in 0.00433 seconds (files took 0.23881 seconds to load)
5 examples, 0 failures

You deploy your new features and move on to your next task. Later, you find out that the front end team reported a bug in your API. Apparently every request they make returns

{
  "error": "Could not find User with 'id'=0"
}

That same day you find out that the marketing team thinks your “new users” endpoint doesn’t work either. Apparently they sometimes get empty results when they shouldn’t. You end up spending the day debugging for your co-workers and eventually figure out what they were doing wrong.

To the front end developer you explain

The API expects the parameter user_id but you specified id. My code ends up getting nil when it tries to get the user_id parameter which is coerced 0 which explains why you always got that error.

moving on to the marketing team you explain

You need to write your dates in the format "YYYY-MM-DD". The problem was when you were searching things like “last December” which ruby parses as December of this year.


What if we ran mutest on this code before shipping it? Running mutest on UsersController we see the following alive mutations:

 def created_after
-  after = Date.parse(params[:after])
+  after = Date.iso8601(params[:after])
   render(json: UserFinder::Recent.call(after))
 end

 def created_after
-  after = Date.parse(params[:after])
+  after = Date.parse(params.fetch(:after))
   render(json: UserFinder::Recent.call(after))
 end

 def show
-  render(json: UserFinder.call(params[:user_id].to_i))
+  render(json: UserFinder.call(Integer(params[:user_id])))
 rescue UserFinder::RecordNotFound => error
   render(json: { error: error.to_s })
 end

 def show
-  render(json: UserFinder.call(params[:user_id].to_i))
+  render(json: UserFinder.call(params.fetch(:user_id).to_i))
 rescue UserFinder::RecordNotFound => error
   render(json: { error: error.to_s })
 end

Mutest is helping me reduce the side effects that my application will permit. These four mutations eliminate subtle bugs which produce misleading errors and incorrect output.

1. Requiring parameters with Hash#fetch

Date.parse(params[:after])Date.parse(params.fetch(:after))

In both actions before we used Hash#[] which implicitly returns nil if the specified key is not present. Hash#fetch on the other hand will raise an error if the specified key is not present. As a result, mutest makes me think about the use case where an implementer of the API does not provide an expected parameter.

2. Better type coercion with Kernel#Integer

params[:user_id].to_iInteger(params[:user_id])

In UsersController#show we called #to_i on our user_id parameter. This ended up coercing nil into 0 which made our final error message more confusing. #to_i will do its best to coerce any input, but this is often not what we want:

nil.to_i     # => 0
'hello'.to_i # => 0

Mutest replaces this with Kernel#Integer which is more strict:

Integer(nil)     # => TypeError: can't convert nil into Integer
Integer('hello') # => ArgumentError: invalid value for Integer(): "hello"

3. Rejecting invalid dates with Date.iso8601

Date.parse(params[:after])Date.iso8601(params[:after])

In UsersController#created_after we called Date#parse which tries to parse any string it thinks could be a date. This sounds handy, but in practice it often can be a subtle source of bugs since all it really needs to see are two adjacent numbers or three letters which could be a month abbreviation:

# Seems useful!
Date.parse('May 1st 2015')      # => #<Date: 2015-05-01>
Date.parse('2015-05-01')        # => #<Date: 2015-05-01>

# Never mind
Date.parse('Maybe not a date')  # => #<Date: 2015-05-01>
Date.parse('I am 10 years old') # => #<Date: 2015-10-10>

Ruby has many more specific date parsing methods. In this case mutest found that iso8601 still works with the tests cases we specified:

# Actually useful!
Date.iso8601('2015-05-01')        # => #<Date: 2015-05-01>
Date.iso8601('May 1st 2015')      # => invalid date (ArgumentError)
Date.iso8601('Maybe not a date')  # => invalid date (ArgumentError)
Date.iso8601('I am 10 years old') # => invalid date (ArgumentError)

Each mutation was better fit for the use case in question. The replacement methods were more likely to throw errors when given unexpected input. Knowing this during the development cycle causes me to handle these edge cases since I don’t want an exception to go uncaught and produce an application error. Even if I do forget to cover one of these use cases though the alternative is still preferable: an exception is thrown in production instead of weird behavior silently degrading my app’s quality for months. I know about the error the first time a user triggers it instead of the first time a user complains.

Add mutest to your workflow

Mutest is a powerful tool for improving your code. At BlockScore we try to reach 100% mutation coverage before code is shipped to production. You don’t have to aim for 100% coverage though to start benefiting from tools like mutest. Simply running mutest against your codebase and seeing what it can change should help you better understand what tests you are missing and what code could be improved.

Words to Avoid in Your YC Application

By Chris Morton on October 13, 2015

BlockScore in Y Combinator S14

I have been through YC twice, including with BlockScore, an identity verification and KYC compliance company from the Summer 2014 batch, and have informally helped many with their applications. A common thread among the applications is the use of words which detract from the meaning that people are trying to convey.

Words to avoid

Remember, the best YC application is one where an unrelated party can understand what you do and how well you have done it in the fewest words possible. The following words can detract from your message:

Buzzwords If the Silicon Valley show didn’t put you off of these words, nothing will. revolutionize, disrupt, synergy, innovate, groundbreaking, world-class, unique, advanced, cutting edge, exclusive, unique, advanced, superior, platform, leverage
Snake oil Even though YC now accepts companies where these words could be true, it’s best to try not to describe potential with trite terms. once in a lifetime, game changer, magic, best of breed, pioneering
Diluters In most cases there are better, more succinct words that could be used that are more specific to your situation. super, very, awesome, really, literally, basically, definitely, golden, amazing, honestly, obviously, great
Informal You can keep a light tone without resorting to informal language. lol, haha, btw, 😀
Offensive It can be easy to accidentally offend - do your best to remember your audience. Swearing probably isn’t justifiable. You can use your imagination!
Tropes Everyone has rockstar developers. Explain why your team is great in other words - these are meaningless! ninja, rockstar, guru
Distractors State your accomplishments and plans with confidence. These words only distract from your point. kind of, sort of, much, just

Make sure to do one final pass to remove any extraneous language. If it isn’t essential, remove it. Brevity and conciseness are more pleasing than wordiness. A good example was someone saying that they “started working towards launching a pilot beta.” The extra words made them sound tentative. I suggested they say “pilot planned for November.”

The same advice applies to your video too. Keep it simple and don’t go overboard; just be normal and follow the advice.

After you submit your application

YC will accelerate your journey but don’t let it be the arbiter of your future. Regardless of whether you get into YC, focus on metrics: user growth, revenue growth, and generating profit. I see many founders pause and then stumble after applying to YC. Don’t let that happen to you.

There is still time to apply

As Sam and PG have mentioned, it isn’t too late to apply. Some of the best YC companies are last minute applicants.

Good luck!

Additional resources

YC application

PG’s guide on how to apply to YC

Sam Altman’s AMA on HN

3 non-obvious ways to improve your YC application by Payable

Get Started with CognitoFrictionless, modern identity verification.

Why We Open Source Our Terms of Service

By Alain Meier on October 9, 2015

Terms of service is on GitHub

Most people don’t read terms of service. For some products, it’s not a huge deal - but for ones like ours, it’s imperative that our customers understand what they’re agreeing to. It’s easy to obfuscate your terms of service and update it on a whim forcing your customers to manage their own copies of past terms and create their own red-lined comparisons.

We at BlockScore want to take a different approach to our public contracts. We believe that the burden of contractual clarity is on the seller, not the buyer, so we maintain all of our most important contracts, like our terms of service and privacy policy, in a version controlled repository on GitHub. Not only does this allow customers to track changes that occurred since they signed up, but it also gives them the ability to understand how and why our contracts have evolved to become what they are today.

Our industry, the identity information space, has very complex and stringent regulations. As a result, our contracts and those of our competitors can be difficult to keep track of. We hope that by putting our standard contract online in an easy to understand, versioned format we will be able to help our customers save money on legal overhead. When your customers better understand what you expect of them, they are also better able to comply with your requirements.

We don’t believe that our industry is unique. Many companies can benefit from having more open and transparent contracts. At its most basic level, version controlling your company’s terms of service requires very little work but pays dividends for your customers.

Plans for the future

At the moment, we work with our lawyer to draft new versions of our contracts and then upload the new version in one commit. In the future, we would like to be able to break each change down into its own individual commit affording us the ability to explain every change that occurs. Of course this requires more resources and time, so it will remain something to aspire to for now.

You can read the latest version of our terms on our website.

Get Started with CognitoFrictionless, modern identity verification.

New regulations for e-cigarette and vaping compliance under TX SB97

By Chris Morton on October 8, 2015

Vaping and e-cigarette age verification

Vaping and e-cigarettes have become popular and are starting to encounter similar regulation that has controlled tobacco sales. For instance, Texas passed TX SB97 to extend Health and Safety Code, Title 2, Subtitle H, 161.453 beyond tobacco to include vaping and e-cigarettes.

Companies that are either based in Texas or service Texas residents must now verify the age, date of birth, and address of purchasers starting October 1, 2015. While some sellers have temporarily suspended selling to Texas residents, BlockScore can quickly help you comply with this and similar regulations being enacted in other jurisdictions.

Here is the pertinent text from 161.453 referenced in TX SB97:

(a) A person may not mail or ship cigarettes in connection with a delivery sale order unless before mailing or shipping the cigarettes the person accepting the delivery sale order first:

(1) obtains from the prospective customer a certification that includes:

(A) reliable confirmation that the purchaser is at least 18 years of age; and

(B) a statement signed by the prospective purchaser in writing and under penalty of law:

(i) certifying the prospective purchaser’s address and date of birth;

(ii) confirming that the prospective purchaser understands that signing another person’s name to the certification is illegal, that sales of cigarettes to an individual under the age prescribed by Section 161.082 are illegal under state law, and that the purchase of cigarettes by an individual under that age is illegal under state law; and

(iii) confirming that the prospective purchaser wants to receive mailings from a tobacco company;

(2) makes a good faith effort to verify the information contained in the certification provided by the prospective purchaser under Subdivision against a commercially available database

BlockScore is the simplest way to comply with the requirement to verify age, birth date, and address using a commercially available database as stated above. In your checkout flow, you can collect the required information, submit it to BlockScore, and get a response back from BlockScore in under a second.

As with any compliance program, make sure that you check with your attorney and comply with the other provisions in TX SB97 and 161.453.

Get Started with CognitoFrictionless, modern identity verification.

Selecting an ID verification provider

By Chris Morton on March 11, 2015

Selecting an ID verification provider

There are many factors to selecting an ID verification provider. This post goes through the important points to consider.

Timeline

The amount of time required to engage, negotiate, implement, and verify varies dramatically between providers. Here are the questions to ask.

  • What is the complete process before I can submit my first verification?
  • How quickly can I get access to a test environment?
  • How long will it take to get implementation guides and developer documentation?
  • Do I need to sign an NDA before any engagement?
  • Do I need to get an office inspection? If so, how quickly can I get one scheduled?

The time between finding BlockScore and going live can be as short as one day. Legacy providers have rigid business processes that can take up to six months.

Cost

The cost of implementing, deploying, and operating an ID verification solution varies dramatically between solutions. The hidden costs of the solution can add up to be significantly more than anticipated. Here are some questions to ask.

  • Are there any setup fees?
  • Are there monthly fees?
  • Does the per verification price include essentials such as watchlist and PEP screening? If not, how much extra are these essential services?
  • Is there an extra charge for high risk address checks?
  • Do I need to amend the contract when I add new services?
  • What is the cost to cancel the contract?

BlockScore offers simple, transparent, inclusive pricing with no setup or monthly fees. See the BlockScore pricing page for more information.

Implementation

The complexity and time to implement a solution varies dramatically between identity verification providers. Here are some questions to ask.

  • Do have have to use your API or can I use a dashboard for manual verifications?
  • Are developer and implementation guides available freely?
  • Are SOAP-aware developers required?
  • Are client libraries available to speed integration?
  • What is required to go live with the solution? Must time be scheduled to go live?
  • Is a test environment available? It is the same version as the production environment?

BlockScore provides freely available client libraries, documentation, and a production-equivalent test environment. When you are ready for live access, submit a request and usually get approved within one day. If you only need occasional verifications, our dashboard has a simple graphical interface to perform verifications with zero programming required.

Remaining in compliance

Verifying someone’s identity is the first step, but how do you ensure that customers do not show up on any watchlists now and in the future? Here are the questions to ask.

  • How many watchlists do you check?
  • Do you check more than OFAC lists?
  • How much does it cost to check watchlists? Do I have to pay per list?
  • Do I have to manually recheck my customers against watchlists or can you do that for me?
  • Do you also check for pollitically exposed persons (PEP)?
  • Do I need to use third-party software to parse through your responses?

BlockScore provides a comprehensive watchlist scanning service for US and international watchlists. The service performs initial scans and perpetual rescans at designated intervals to ensure that your business remains in compliance.

Coverage

As your business expands internationally, you need an ID verification provider that covers the countries in which you expand. Here are the questions to ask.

  • Which countries do you cover?
  • If you add additional countries, do I need to change my implementation?
  • If I submit an international verification and no data is available, am I charged?
  • Is your data limited to credit bureaus or do you have other sources?

BlockScore covers many countries throughout the world and never charges for international verifications where no data is available.

References

Upfront, transparent pricing

Freely available documentation

Simple contract terms

Comprehensive coverage

Get Started with CognitoFrictionless, modern identity verification.

New dashboard now available

By Alain Meier on January 14, 2015

For the past few months, we have been working on an improved dashboard experience. All BlockScore businesses will now see it once they login. Though there are dozens of improvements, here are some highlights:

New dashboard homepage

One of our most requested features, search, is now available on the top bar of every page. You can now search universally for all people, companies and candidates and then drill down into specific results using the sidebar.

We have also added the ability to search past results directly using the API. You can read more about how to do that in our documentation.

Brand new interface

The new dashboard now shares the same look and feel as the rest of the BlockScore systems. It is now much easier to find what you are looking for, and we have vastly improved the signup experience and applying for live access. Common actions like verifying new people can now be done right from the dashboard homepage.

Manage candidates

Our comprehensive watchlist scanning system, Candidates, is now accessible from the dashboard. View your searches and any watchlist hits that may have occurred.

Address autocomplete

We have made using the dashboard to verify users easier than ever before by automatically filling in country subdivisions (like states, provinces and cantons) as well as cities once you enter a postal code.

Activity feed

The new dashboard homepage includes an activity feed that helps you stay on top of what is happening in your business.

Support for international documents

The person verification forms now supports all of the forms of documentation that we support on our API.

Comprehensive verification details

After verifying a person or company, we now display all of the details regarding the verification results as well as icons to indicate whether this response is good, bad or neutral.

We hope you enjoy the improvements. If you have any feedback, please message us at support@blockscore.com. There is a lot more to come in the following weeks!

Get Started with CognitoFrictionless, modern identity verification.

Using BlockScore in an app

By Chris Morton on December 8, 2014

BlockScore can be easily implemented in apps. As with any good system design, there are some important points to ensure user data is protected. This post goes through the basics of how to use BlockScore ID verification in an app.

The first step is to design a form to collect the required identity information from your user in your app. From that form, identity information needs to be sent to your server. Always use encrypted channels to communicate between your app, server, and external service providers such as BlockScore. Never store identity information in the app. We also recommend not storing personally identifiable information (PII) on your server because BlockScore can safely store it for you.

The next step is to send the identity information from your server to BlockScore using either our RESTful HTTP API or a client library for your server platform. Many client libraries are available on the BlockScore Github repository. Within a second of sending the information from your server to BlockScore, you will receive a response with valid/invalid, details about the matching pieces of information, and a token to access information about that verification in the future. As mentioned, in lieu of storing the identity information on your server, this token can be used to retrieve identity information from BlockScore.

Once BlockScore has responded with a valid status to your server, store the token in the user’s record. If an invalid status is returned, you may permit the user to retry the verification. We recommend that you limit the number of times the user may retry the verification. A common rate is two verifications per 24 hour period.

BlockScore provides an API key to communicate with our web service. All requests must including this API key. Because this key is also used to retrieve past verification information, it should never be used outside of your server. Never use or store your BlockScore API key on your app.

Optionally, you may request a question set to ensure the person submitting the identity information is the owner of the identity. See BlockScore documentation on implementing question sets.

For app developers with little server development experience, services like Parse provide an easy way to run the necessary server software to support your apps.

Get Started with CognitoFrictionless, modern identity verification.

How ID verification works

By Chris Morton on December 6, 2014

BlockScore is an identity verification service that uses many data sources to verify the identity of your customers or users. The goal of the verification is to take information provided by a user, see if the a coherence of that information matches various data sources, and return the results to you for compliance and fraud mitigation.

Unlike single-source providers such as credit bureaus, BlockScore uses not only BlockScore data, but data from many sources to verify identity information. When identity information is submitted, proprietary algorithms compare the identity information provided against various data sources and within a second, return both a simple valid/invalid and details about the match strength of each piece of data provided by the user. For many businesses, a valid/invalid response is sufficient. For more sophisticated risk models, the details can be used.

Optionally, BlockScore offers a question set service, also known as KBA (knowledge-based authentication). After a verification is performed on a person and determined to be valid, you may request a question set comprised of five questions. These questions are used to determine if the owner of the identity is submitting the identity information to you. You may present the user with as few questions as you like. After you collect the answers to the questions from the user, send the answers to BlockScore and you will receive the results in under a second.

In addition to verifying that the identity information is for a real person, the information can also be checked against several watchlists simultaneously. See watchlist scanning for more information on supported lists.

Get Started with CognitoFrictionless, modern identity verification.

Best practices for ID verification

By Alain Meier on December 5, 2014

Customers often ask us for the best practices when putting together their BlockScore verification integration. We have seen many custom integrations, some good, some bad. In this article we have compiled a list of tips to maximize pass rates and minimize customer frustration.

Reduce required input fields

For most businesses, your users don’t use your service because of ID verification; they use it in spite of it. Reducing friction is paramount for improving your user experience and this can be achieved by only asking the bare minimum of what is required for your purposes. One convenient optimization is to pre-fill a user’s city and state based on their postal code. Though this isn’t possible for every country in the world, it is possible for most.

One of the most common reasons for a false failure is the use of an incorrect address or nickname. If your customer enters their work address or the address of a home to which they only recently moved, their verification will likely not pass. Let them know that they should use an address that they have associated with their bank of credit card for the best chance of success. In addition, the “name” fields should be labelled “legal name” so as to prompt people not to use nicknames when filling out the form.

Show the correct forms of ID based on country

If you are verifying an international audience, it is best to customize the forms of identity based on the country they live. For instance, if your customer is in the United States, you would use the language SSN and Driver’s License as means of verification. However, if your customer is in Mexico, they can use their Matricula Consular or Passport. This is much clearer and easier to understand than something like document number or ID number.

Properly format the address field based on country

Every country has its own peculiarities when it comes to addresses. For instance, not every country has postal codes and the subdivision that is referred to as “state” in the United States has a variety of equivalents in other countries such as the Swiss “canton” or the Canadian “province”. If your customers come from across the world, localizing the fields based on language they understand will greatly improve accurate data entry.

Explain why you need the information

Depending on your audience, people may not understand why your business is asking for their sensitive information. Even mammoth companies like Target are subject to being hacked, so it is no wonder people are sometimes a bit weary of handing over their data. A few sentences before the ID verification form as to why you need to collect this info can go a long way towards improving your customer’s trust.

Give them a way to correct a failure

Sometimes good people do not pass the ID verification process. This can happen for a variety of reasons beyond the person’s control, so it is important to provide some form of recourse. Whether that means allowing the customer to upload a scanned physical document or to provide a way to contact support, making sure that people have an alternative means turning away fewer good customers.

After making these simple changes, your BlockScore integration will convert more people and be much more enjoyable to use. If you have any more questions, we’d love to hear from you at support@blockscore.com.

Documentary versus electronic ID verification

By Chris Morton on December 4, 2014

There are many ways to verify an individual’s identity but they broadly fall into two categories: documentary and electronic ID verification.

Documentary ID Verification

Documentary ID verification passport

Documentary ID verification is the method to verify the authenticity of physical documents. When in person or submitting paperwork, copies of documents such as identity cards, birth certificates, legal documents, and utility bills provide the basis to verify the authenticity of the person providing the information. These documents may be certified copies, be embossed with seals, or have holograms to provide evidence of authenticity. The conclusion is that only person possessing these documents and having similar characteristics to the person stated on the documents such as photos, sex, addresses, and schooling is likely to be the person owning the identity.

Advantages

  • Easy to perform sufficient photo ID verification in person
  • Provides sufficient hurdles to deter most fraudulent activity
  • Documents may be the only method available to verify a person’s identity

Disadvantages

  • Challenging to perform when not in person
  • Authenticating most documents is impossible or cost prohibitive because it requires sending the documents to the issuing authority
  • Many types of documents may be not be available due to loss, fire, floor, or insufficient record keeping
  • People are less likely to keep utilities in their names which makes proof of residency challenging

Electronic ID Verification

Electronic ID verification computer

BlockScore provides a electronic ID verification method to verify the identity of a person meaning that only knowledge is required. Information that only the owner of the identity is likely to know is checked against authoritative sources for authenticity. Additionally, the authoritative source may also prompt the person being verified for additional information to further verify his or her authenticity. The additional questions returned from authoritative sources is called question sets or knowledge-based authentication (KBA).

Advantages

  • Easy and cost effective to check against many authoritative sources quickly
  • Additional screenings can easily be performed such as checking against government watchlists
  • Works well over the Internet
  • May fulfill compliance obligations

Disadvantages

  • Authoritative sources may not be available to check against in certain countries and among certain demographics
  • Privacy laws may prohibit using authoritative information to verify a person

Combining documentary and electronic ID verification methods

Businesses can use both documentary and electronic ID verifications together to mitigate risk and comply with regulations. In many jurisdictions, electronic ID verification is required to ensure that it is legal to do business with a person by checking the person against watchlists. Automated documentary ID verification, such as Jumio Netverify, can be added to the user flow as part of the signup process or when certain events occur such as large transactions. Information extracted by using automated documentary ID verification such as Netverify can be sent directly to BlockScore for electronic ID verification simultaneously.

Conclusion

Businesses have options to balance the impact to users and the need to verify the identity of individuals to comply with regulations and mitigate fraud. Documentary, electronic, or both methods of ID verification can be implemented to minimize the impact to users at various places in the signup flow and ongoing relationship. BlockScore provides the easiest-to-implement electronic ID verification service and works with others such as Jumio for documentary ID verification.

Get Started with CognitoFrictionless, modern identity verification.