Posts Tagged ‘Address Validation International’

For companies who deal with users in the United Kingdom, this reference guide can help you better understand how addresses in the UK are formatted and what makes an address valid.

Understanding Addresses in the United Kingdom

For companies who deal with users in the United Kingdom, this reference guide can help you better understand how UK addresses are formatted and what makes an address valid.

The United Kingdom: Three Nations, One Province, 29 Million Addresses

The United Kingdom of Great Britain and Northern Ireland – commonly referred to as Britain, the United Kingdom, or simply the UK – is made up of three nations and one province: England, Scotland, Wales, and Northern Ireland. There are approximately 29 million known deliverable addresses in the UK, with over five thousand addresses being added and removed monthly.

International Country Code

The International Organization for Standardization (ISO) published the ISO 3166 standard, officially known as Codes for the representation of names of countries and their subdivisions.

The ISO 3166 standard consists of three parts:

Part 1:
ISO 3166-1
Country Codes – defines codes for the names of countries, dependent territories, and special areas of geographical interest.
Part 2:
ISO 3166-2
Country subdivision code – defines codes for the names of primary subdivisions of a country, such as a state or a province.
Part 3:
ISO 3166-3
Code for formerly used names of countries – defines codes for country names that have been removed from ISO 3166-1.

 

ISO 3166-1, which defines country codes, contains three sets of country codes:

ISO 3166-1 alpha-2: Defines a country as a two-letter country code, commonly referred to as the ISO, ISO2, or ISO-2.
ISO 3166-1 alpha-3: Defines a country as a three-letter country code, commonly referred to as numeric-3, ISO3, or ISO-3.

 

ISO 3166-1 Country Codes – United Kingdom

ISO 3166-1 alpha-2 code ISO 3166-1 alpha-3 code ISO 3166-1 numeric code
GB GBR 826
Note that the alpha-2 code is GB and not UK.

 

ISO 3166-2 Country Codes

In the ISO, England, Scotland, Wales, and Northern Ireland are not included in the ISO 3166-1 country list and are instead listed as subdivisions of GB in ISO 3166-2. However, their subdivision description is that of “country,” except for Northern Ireland, which is described as a “province.”

ISO 3166-2 code Subdivision Name Subdivision category
GB-ENG England Country
GB-SCT Scotland Country
GB-WLS Wales Country
GB-NIR Northern Ireland Province

 

UK vs. GB Country Code – FIPS vs. ISO 3166-1

The United States Federal Government developed the Federal Information Processing Standards (FIPS) for use in computer systems by non-military government agencies and government contractors. Country codes are defined in the FIPS 10-4 standard, where the United Kingdom is listed as UK and not GB. However, where the FIPS 10-4 codes where defined for use in computer systems, the standard has been dropped by many institutes and agencies in preference to ISO 3166-1, making ISO 3166-1 alpha-2 the global standard.

Postal Services

Mail in the United Kingdom is primarily handled by Royal Mail. Royal Mail was established in 1516 by King Henry the VIII, and it was government owned for 499 years. There are other mail delivery services available in the market, but many of them use Royal Mail for the last mile delivery.

Address Format

The address format for mail delivery in the United Kingdom is defined by Royal Mail, where an address is made up of four elements. The elements should appear in the following order:

Address Element: Address Example: Element Names:
Premise Royal Mail
Flat 9, Wheatstone House
[Organization]
[Sub-Building], [Building Name]
[Building Number]*
Thoroughfare 47* Gorse View
School Road
[Dependent Thoroughfare]
[Thoroughfare]
Locality Southampton
Knodishall
Saxmundham
[Double Dependent Locality]
[Dependent Locality]
[Post Town]
Postcode SWA1AA [Postcode]

*NOTE: Although the building number appears with the thoroughfare, it is part of the Premise element.

Premise Elements

A mailing address premise is made up of the following elements:

Order Premise Element Name Description Example
1 Organization The name of the organization, and when necessary the name of the department within the organization, which is registered to the delivery address. Royal Mail
2 Sub-Building This is also known as a sub-premise, such as an apartment, flat, or suite. Flat 9
3 Building Name The name of the building of the business or residence. Wheatstone House
4 Building Number Also known as the premise number or address number, this number identifies the premise on the thoroughfare or dependent thoroughfare. 47

 

Not all elements are required, but enough must be given to identify a single unambiguous delivery point. Also, note that while the building number is a part of the premise element, it must be applied on the same line as its corresponding thoroughfare.

Thoroughfare Elements

A thoroughfare premise is made up of the following elements:

Order Thoroughfare Element Name Description Example
1 Dependent Thoroughfare Distinguishes a premise when a thoroughfare appears more than once in a post town. Gorse View
2 Thoroughfare This is also known as the street or road. School Road

 

Royal Mail defines three thoroughfare address possibilities:

  1. Thoroughfare without a dependent thoroughfare – When an address does not include a dependent thoroughfare, the element is to be omitted.
  2. Thoroughfare with a dependent thoroughfare – When an address contains both elements, Royal Mail instructs that the dependent thoroughfare is required and the thoroughfare is optional.
  3. No Thoroughfare – Not all addresses contain a thoroughfare, in which case the thoroughfare element is simply omitted.

Example:

Her Majesty the Queen
Buckingham Palace
London
SW1A 1AA

Locality Elements

The mail address Locality is made up of the following elements:

Order Locality Element Name Description Example
1 Double Dependent Locality Distinguishes a premise when an address thoroughfare appears more than once in the same post town and dependent Locality. Southampton
2 Dependent Locality Distinguishes a premise when an address thoroughfare appears more than once in the same post town. Knodishall
3 Post Town Also known as the Locality; however, the post town represents the postal delivery Locality and not necessarily the geographic Locality. Saxmundham

 

Other aspects of Locality elements you should be aware of:

1. The Post Town is required.
2. The initial letter of the Post Town must always be capitalized.
3. The Post Town may be written in all capital letters (uppercase). It is the only Locality element where this is allowed.

Postcode

The postcode is made up of the following elements:

Order Element Name Description Example
1 Postcode Also known as a postal code, this is an alpha-numeric code that is associated with one or more addresses along one or more thoroughfares. SW1A 1AA

 

The postcode must be written in all capital letters (uppercase) and must be the last address element. Royal Mail recommends that the postcode be listed as a singular element on the last line of the address; however, it may be preceded by either the county or post town on the same address line when separated by a space or on the preceding line.

Regarding County

Though the geographic county of an address is not required, according to the Royal Mail website regarding the inclusion of county, “you are welcome to do so.” However, the issue of listing geographic counties and postal counties has been the cause of some confusion over the years. Counties were removed from the address elements in the early 2000s, and they are no longer officially supported. This was due, in some part, to the boundaries of postal counties and geographic counties not matching up, so an address in one geographic county would be listed in a postal county of a different name.

Postcode Overview

The postcode is an alphanumeric code of varying length that is composed of two codes called the outward code and inward code. It ranges from six to eight characters in length with a single space to separate the two codes. A postcode may represent a group of addresses on a street or on a part of a street, a group of premises, or a single premise. On rare occasions, it may also represent a group of addresses on more than one street.

Postcode Format

Outward code

1. Postcode area
2. Postcode district

Inward Code

1. Postcode sector
2. Postcode unit

For example, in the postcode “SW1A 1AA” we have the following:

Name Example
Postcode SW1A 1AA
Outward code SW1A
Postcode area SW
Postcode district SW1A
Inward code 1AA
Postcode sector SW1A 1
Postcode unit AA

Outward Code

The outward code represents the first half of the postcode that precedes the single space separator. It is made up of the postcode area and postcode district. The length of the outward code is between two and four characters.

Postcode Area 

The postcode area is an alpha code that is one or two characters in length. The code commonly represents a geographical area. For example, “SW” represents London, “AB” is commonly Aberdeenshire, “BS” is often Avon, and so on.

Postcode District 

The postcode district is the postcode area plus an alphanumeric code, essentially making it the outward code.

Inward Code

The inward code represents the second half of the postcode, immediately following the single space separator in the middle. It is three characters in length. The inward code is used to assist in the delivery of mail within a district.

Postcode Sector 

The postcode sector is between four and six characters in length. It begins with the outward code, followed by the single space separator, and ends with the first digit of the inward code.

Postcode Unit 

The postcode unit is an alpha code that is two characters in length. In addition to representing a group of addresses, the postcode unit may also represent a unique premise, an individual organization, or even a subsection/department of an organization. Postcode unit level designation cannot be purchased; it is determined by the amount of mail received by the premises or organization.

Special Postcodes

Royal Mail will assign postcodes to some high-profile organizations such as banks and telecoms, as well as non-geographic postcodes for assignment to PO Boxes and direct marketing. It will also assign postcodes to crown dependencies, overseas territories, and HM British Forces.

Crown dependencies

The crown dependencies are three self-governing island territories off the coast of Britain for which the United Kingdom is responsible. However, they are not a part of the United Kingdom or its territories. These islands have adopted the UK postcode format.

Name Postcode area
Guernsey GY
Jersey JE
Isle of Man IM

Overseas Territories

There are 14 overseas territories in the United Kingdom. They may be commonly referred to as British Overseas Territories or the United Kingdom Overseas Territories. These territories are mostly self-governed, and some have developed their own postal codes, such as Bermuda, the Cayman Islands, the British Virgin Islands, and Montserrat.

British Forces Post Office

The British Forces Post Office (BFPO) and Royal Mail use the non-geographic postcode area “BF” to represent a BFPO address.

Address Validation International: Overcoming Cultural Idiosyncrasies and Postal Format Variables

The above content provides a general overview of addresses in the United Kingdom. Understanding all the ins-and-outs of UK addresses can be a monumental task on its own. In addition, the ever-changing list of addresses, postcodes, and regulatory boundaries involved can make for a very dizzying array of challenges. Fortunately, the DOTS Address Validation International real-time service is capable and robust enough to handle various address formats and cultural idiosyncrasies. As always, our experienced staff is here to help, so please do not hesitate to reach out to us! We would be happy to answer any follow-up questions you may have and make recommendations on how to interpret and use the results from the service.

 

 

 

DOTS Address Validation International (AVI) enables businesses to develop consistent addressing formats for your international addresses.

AVI Address Output: We Speak Your Language

You say tomato, I say tomahto.
You say Rome, I say Roma.
You say Munich, I say München.
Let’s Not call the whole thing off.

Have you ever wondered why the country code and abbreviation for Germany is DE, or similarly why it is ES for Spain? Unlike FR and CA, which are France and Canada respectively, DE and ES seem out of place for Germany and Spain. A simple explanation is that DE is short for Deutschland and ES is short for España – which are the names used locally for these countries.

Local names such as Deutschland and España are known as endonyms, and Germany and Spain are English language exonyms. You may be wondering, what are endonyms and exonyms? To put it simply, endonyms are the names of places used by the locals and exonyms are the names used by foreigners. So an endonym is what a country calls itself, and an exonym is the name used by other countries.

(As another example, United States is an endonym for, well, the United States. Meanwhile, exonyms for the United States will depend on the country involved: the French call us the États Unis and the Russians call us Соединенные Штаты.)

The DOTS Address Validation International (AVI) service currently offers three output language options to let the end user choose their preferred language setting and behavior: ENGLISH, BOTH (English and local addresses), and LOCAL_ROMAN. Let’s examine each of these in detail:

ENGLISH – Instructs the service to return the address in English, without any localized text or accents.

BOTH – Instructs the service to return a standardized address in both English and in its localized text (e.g., Cyrillic, Chinese, etc.) and format when applicable.

Here’s an example of a Chinese address in both English and in its local Chinese text.

Address input in English

No. 1514 Changyang Lu
Yangpu Qu, Shanghai Shi

Address output in Simplified Chinese

上海市杨浦区长阳路1514号

 

Here’s an example of a Russian address in both English and Cyrillic.

Address input in English

Kommunarov Ul, 290, 9
Krasnodar
Krasnodarskiii Kraii
350020

Address output in Cyrillic

Коммунаров ул, д. 290, OFFICE 9
КРАСНОДАР
КРАСНОДАРСКИЙ КРАЙ
350020

 

One last example, this time in Greece.

Address input in English

Alkamenous 76
104 40 Athens

Address output in Greek

104 40 Αθηνα
Αλκαμενους 76

 

LOCAL_ROMAN – Instructs the service to return the address in its local spelling using Roman text.

For example, the city of Rome will be returned as Roma, Naples as Napoli, Dublin as Baile Átha Cliath, Naestved as Næstved, and Cologne as Köln. Let’s take a look at some address examples.

Here’s an example of an address in Italy.

Address input in English

Via Villafranca 20
00185 Rome RM

Address output in Italian

Via Villafranca 20
00185 Roma RM

 

Example of an address in Denmark

Address input in English

Kobmagergade 20
4700 Naestved

Address output in Danish

Købmagergade 20
4700 Næstved

 

Example of an address in Germany.

Address input in English

Weisshausstr. 20-30
50939 Cologne

Address output in German

Weißhausstr. 20-30
50939 Köln

 

The service also has the ability with some countries to accept an address in its localized spelling and text and return the address in English. Try entering any of the address examples above into the AVI service using the local language, spelling, and format with the output language set English to see the address validated and standardized into English. When submitting an address in a non-English language, be careful to ensure that the text is properly encoded.

The AVI service cannot correct corrupted characters, so it is important to ensure that anything that will hold the address in memory and stores the data can support the character set. Otherwise, you will end up with data corruption, which is not always easy to detect or fix.

For example, in some cases, a character may simply come back as a question mark ‘?’ or a square ‘■’. Take the following address.

Weißhausstr. 20-30
50939 Köln

The fourth character of the first line and the eighth character of the second line will come back corrupted, as follows:

Weihausstr. 20-30
50939 K?ln

 

In other cases, the corruption can be quite severe, and you may end up with something like ‘تخت اره ÙŠÚ©’. Not only is it important to ensure that you do not send any corrupted data to the AVI service, but you also want to make sure that you properly handle and store the service response. Otherwise you may end up corrupting an address after it has been validated. (How this happens would make a good topic for another blog, but for now, just make sure to use the Unicode Transformation Format (UTF) on everything that handles the data.)

Each of these options gives you the flexibility to have a consistent addressing format for your international addresses, depending on your location, your customers, and your mailing conventions. All of them provide an automated, consistent approach to address validation. Whether it is addressing mail to customers in the format of their home countries, translating addresses, or ensuring readability for the sender, DOTS Address Validation International truly speaks your language.

Address Suggestion with Validation: A Match Made in Heaven

In an ideal world, data entry would always be perfect. Sadly, it isn’t – human errors happen to end users and call center employees alike. And while we make a good living cleaning existing bad data here at Service Objects, we would still much rather see your downstream systems be as clean as possible.

To help with that, many organizations are getting an assist with Google, in the form of the Autocomplete with their Places API.  If you setup your form properly and use their API you can have address suggestions appear in a dropdown for your end users to take advantage of to help enter correct data into your system. That’s great, isn’t it?

It does sound great on the surface, but when you dig a little deeper there are two problems:

  • First, Google Places API often does not often suggest locations to the apartment or suite level of detail. The point is that a considerable segment of the population lives in apartments or does business on separate floors, suites or buildings.
  • Second, the locations the Google Places API suggests are often not mail deliverable. For instance, a business may have a physical location at one address and receive mail at a completely different address.  Or sometimes Google will just make approximations as to where an address should be.

For example, check this address out on Google Maps: 08 Kings Rd, Brighton BN1 1NS, UK.  It looks like a legitimate address, but as the street view shows, it does not seem to correspond to anything.

These issues can leave gaping holes in your data validation process.  So, what can you do? Contact us at Service Objects, because we have the perfect solution: our Address Suggestion form tool. When combined with the Google Places API you will have a powerful tool that will both save time and keep the data in your system clean and valid.

This form tool is a composite of the Google Places API and our Address Validation International service.  The process consists of the data entry portion, the Google Paces API lookup, then the Address Validation International service call, finally displaying selectable results to the end user.

Let’s start by discussing the Google API Key, and then the form, and finally the methods required to make that Google Places API call.

Google Places API requires a key to access it.  You can learn more about this API here.  Depending on your purposes you may be able to get away with using only Google’s free API key but if you are going to be dealing with large volumes of data then the premium API key will be needed.  That doesn’t mean you can’t get started with the free version: we in fact use it to put our demos together, and it works quite well.

When setting up your key with Google, remember to also turn on the Google Maps Javascript API, or else calls to the Places API will fail.  Also, pay particular attention to the part about restricting access with the API key.  When you have a premium key this will be very important because it will allow you to set the level at which you want the key to be locked down, so that others can’t simply look at your Javascript code and use your key elsewhere.

The form we need to create will look like a standard address data entry form, but with some important details to note.  First let’s look at the country select box: we recommended that this be the first selection that the user makes. Choosing a country first benefits both you and the user, because it will limit suggested places to this country, and will also reduce the number of transactions against your Google Places API key.  Here is a link to how Google calculates its transaction totals.

Another important note is that we need to have the Apt/Suite data entry field.  As mentioned earlier, the Google Places API often does not return this level of resolution on an address, so we add this field for the information be provided by the end user.

The rest of the fields are really up to you in how you display them.  In our case, we display the parsed-out components of the results from selected address back into the rest of the address fields.  We keep all the address input fields editable so that the end user can make any final adjustments they want.

The methods associated with this process can be summarized by a set of initializations that happen in two places: first, when a country is selected, and second, when the focus is on the Address field by a user clicking into it.  For our purposes we default the country selection to the United States, however when the country is changed the Autocomplete gets reinitialized to the selected country. And when a user clicks into the Address field, the initialization creates a so-called bias, e.g. Autocomplete returns results based on the location of your browser.  For this functionality to work, the end user’s browser will ask to let Google know its location.  If the user does not permit Google to know this the suggestion is turned off and does not work.

This bias has a couple of interesting features.  For instance, you can change the code to not utilize the user’s browser location but instead supply a custom latitude and longitude.  In our example, the address suggestion does not end up using the user’s current position when the selected country is not in the same country as the user.  But when the user is in the same country as the selected country then the results returned by the Google Places API are prioritized to your location.  This means that if you are in Santa Barbara, CA and select the United States as the country, when you start typing a United States address you will first see matching addresses in Santa Barbara, and then work outward from there.

You can customize the form bias to any particular location that you have a latitude and longitude for.  The ability to change this bias is very useful in that setting the proper bias will reduce the number of lookups against the Google Places API before finding an address match, and will also save manual typing time.

Now let’s discuss the Address Validation International service API call, which consists of a key, the call to the service and setting up best practices for failover.

Let’s start with the key.  You will need to either have a live or free trial license key from us, the latter of which can be gotten here.  For this example, a trial key will work fine for exploring and tinkering with this integration.  One of the great things about using our service is that when you want to turn this into a live production-ready solution, all you have to do is switch out the key from the trial to the production key and switch the endpoint to the production URL, both of which can be done in minutes.

The call to the Address Validation International service will be made to either the trial or production endpoints, which will depend on the key that you are using.  The details of the service and how to integrate with it can be found in our developer guides.  In the Javascript code you will round up all the data in the fields that were populated by the address suggestion selection and send them off to the service for validation.  The code that manages the call to the Address Validation International service needs to be executed on some back-end server client.

It is strongly discouraged to make the call to the service directly from Javascript, because it will expose your license and allow someone to take it and use your transactions maliciously.  You can read more about those dangers here.  Also, here is a blog about how to make a call to another one of our services using a proxy.  The basic idea is that your Javascript call will call the proxy method that contains your license key, essentially hiding it from the public.  This proxy method will make the final call to the Address Validation International service, get the results from it and pass those results back to the original call in the Javascript.  In this situation, the best place to implement failover is in the proxy method.

So what is failover? Failover, from the perspective of an end user developer, is just a secondary data center to call in the unlikely event that one of our primary data centers go down or does not respond in a timely manner.  Our developer guides can again help with this topic.  There you will also find code snippets that demonstrate our best practice failover.

Once this call is set up, all that is left is evaluating the results and displaying the appropriate message back to the end user. While you can go through our developer guides to figure this out, the first important field to examine in the response from the Address Validation International service is the Status field – here is a table of what is expected to be returned:

Address Status

Name Description
Invalid For addresses where postal and/or street level data is available, and the street was not found, bad building number, etc.
InvalidFormat For addresses where Postal data is unavailable and only the address format is known.
InvalidAmbiguous For possibly valid addresses that may be correctable, but ultimately failed validation.
Valid For addresses with postal level data that passed validation.
ValidInferred For addresses where potentially far reaching corrections/changes were made to infer the return address.
ValidApproximate For addresses where premise data is unavailable and interpolation was performed, such as Canadian addresses
ValidFormat For addresses where Postal data is unavailable and only the address format is known.

 

Another important field will be the ResolutionLevel, which can be one of the three following values: Premise, Street and City.  The values returned in these two fields will help you make a decision in the code with respect to what exactly you want to display back to the end user.  What we do in our demo is display the Status and ResolutionLevel to the end user along with the resulting address.  Then we give the user a side-by-side view of both the resulting address just mentioned and the original address the user entered.  This way the end user can make a decision based on everything we found. In the case shown here, for example, we updated Scotland to Dunbartonshire and validated to the premise resolution level.

There are many customizations that can be made to this demo, such as the example we mentioned earlier about setting up the bias.  Additionally, instead of using the Address Validation International service you could also create an implementation of this demo using our Address Validation US or our Address Validation Canada products.

Want to try this out for yourself? Just contact one of our Account Executives to get the code for this demo – we’ll be glad to help.

Our 2018 New Year’s Resolutions

A brand new year is upon us – and once again, many of us are making resolutions for 2018. Perhaps eating better, working harder, or even blowing a thick layer of dust off that exercise machine in our basement. The new year is always a great time to make a fresh start.

Here at Service Objects, we have our own resolutions for 2018 as well. Of course, ours are designed to help your 2018 marketing efforts be even more successful than last year. Here are some of the biggest ones on our list:

Automate your regulatory compliance. More than anything, 2018 will cap a growing era of global consumer rights and stiffer regulation. Between the pending May implementation of the European Union’s General Data Protection Regulation (GDPR) and the recent expansion of the US Telephone Consumer Protection Act (TCPA), your use of consumer contact data for marketing is more tightly controlled than ever. And ignorance of the law isn’t bliss: fines for TCPA violations run as high as $15,000 per violation, and GDPR violations can command fines as high as 4% of your gross turnover.

We can help you get started on your path to achieve compliance with both of these new regulations. For GDPR, which requires maintaining explicit customer permission for use of their personal data, products such as Address Validation International, Lead Validation International and Email Validation can flag European addresses for GDPR processing and clean your contact database at time of use. And for TCPA, which prohibits unsolicited calls to consumer cellular numbers, our GeoPhone Plus product can help ensure that customer contact numbers haven’t been ported to new mobile customers.

Help you move into global markets. The world is getting smaller every year, which means that your potential market is getting larger. We can help you validate and verify international leads with tools such as Address Validation International and Lead Validation International, to help you target your overseas marketing more effectively.

Reduce the amount of fraud in eCommerce transactions during sales peaks. Did you know that 2017 saw the largest online sales volumes ever for Black Friday and Cyber Monday? According to data from Adobe Analytics, consumers spent a record $11.6 billion dollars across these two peak sales days – and according to Forbes Magazine, fraudulent transactions spike during these peak periods as well. We have a wide range of solutions for eliminating online fraud, ranging from lead validation to best practices such as validating IP addresses, to ensure that order from Kansas isn’t originating in Kyrgyzstan.

Give your customers a better experience. Your business rises and falls with the service experiences you deliver your customers. Our flagship delivery accuracy solutions, powered by continually-updated USPS, Canada Post and international address databases, makes sure your products get to the right people at the right address every time. And even when customers slip up and give you an undeliverable address, our Address Detective product can help make things all better.

Lower your costs. Would you like to get better lead response rates in 2018? Keep your contact database clean and up-to-date as prospects move or change jobs? Or improve your marketing ROI by filtering out bogus or fraudulent leads? We can do all of that for you, and more. We have a whole smorgasbord of solutions that help you have genuine, accurate and up-to-date data, improve marketing campaign performance, ensure better leads, and do more with less.

One more thing that makes our New Year’s resolutions better than most people’s – we always keep ours! That’s why we have over 2400 clients and counting today. And we look forward to serving you in 2018.

GDPR Compliance: Is Your Business Ready?

If you conduct business in Europe, May 2018 will be an important date. This is when the planned introduction of the European Union’s General Data Protection Regulation (GDPR) is scheduled to take effect.

GDPR represents a sweeping set of privacy regulations that impact your use of personal data from European citizens. If you conduct business with people from Europe – whether they are your customers, employees, or job prospects – GDPR affects you as well. It will require you to have policies in place to protect people’s personal data, as well as require notification when this data has been breached. And penalties for violations will be extremely stiff, up to the greater of 20 million Euros or 4% of your gross turnover.

GDPR starts with the definition of “personal data.” This is an extremely broad net: a recent article from Software Development magazine notes that the European Commission’s guidelines include both obvious data such name, address or email, and associated data ranging from bank accounts to photos and social media posts. Even the IP address a European is using on their computer is considered part of this personal data.

Much like the HIPAA requirements on electronic health care data in the United States, GDPR will require organizations to safeguard the personal data they collect and store in the course of doing business. At one level, this will involve technology such as encrypted data storage, password protection, and other approaches, along with policies and procedures for protecting this data. At another level, it obligates you to inform European consumers about your privacy policies, gain explicit consent to collect and use their personal data and provide them with the ability to control or opt-out of data collection. And in the event personal data is compromised, you need a plan for reaching people affected by the breach.

Each of these levels have important areas where data quality and GDPR compliance efforts intersect. Some of the questions businesses will have to ask themselves include:

  • Do we have accurate contact information for people we do business with in Europe?
  • Is there a notification procedure in place for our privacy and data policies, including opting out of data collection or making changes to personal data?
  • If a breach notification were necessary, do we have the means to quickly reach all affected parties?
  • How do we handle changes to contact information? What if a person in your database moves, changes jobs, or gets a new email address?

This means that your GDPR and data quality strategies will need to be closely linked. Tools such as international address verification, lead validation and name validation can help make sure data is complete and correct as it enters your system, and stays correct when it is needed later. As a recent article in Information Management points out, the key to GDPR compliance lies in proactively analyzing your data and performing a thorough risk assessment long before an actual privacy issue arises.

The European Union has long been on the vanguard of consumer protection legislation, and the new GDPR regulations are the latest in an effort to level the playing field between big data and the individual rights of its citizens. They have a global reach, whether you do business in Europe or serve Europeans from elsewhere. At a broader level, GDPR is part of a new reality that businesses will soon need to work with, one that is part of a larger trend toward increasing privacy regulations.

May 2018 is coming soon – is your business ready?

The Importance of Data Quality for International Ecommerce

In today’s era of online ecommerce, international sales represent a huge potential market for US vendors. According to research firm eMarketer, international sales represent three-quarters of a nearly US $2 trillion retail ecommerce market, nearly half of which comes from China alone. And much of this vast market is only a click away.

On the other hand, cross-border sales remain one of the greatest risks for fraud, with a rate that was more than twice that of domestic fraud through 2012, and despite recent improvements in data quality technology this rate is still 28% higher as of 2015. And one digital commerce site notes that while retailers are making progress at managing fraudulent transaction rates, they are doing so at the expense of turning away good customers – people who, in turn, may never patronize these sites again.

So how do you exploit a rich and growing potential market while mitigating your risk for fraud? The answer might surprise you. While nearly everyone preaches the importance of a fraud protection strategy for ecommerce, and suggestions abound in areas that range from credit card verification to IP geolocation, the head of ecommerce at industry giant LexisNexis points to one area above all: address verification.

In a recent interview with Multichannel Merchant, LexisNexis ecommerce chief Aaron Press points out that the biggest problem with international addresses is a lack of addressing standards between countries. “Postal codes have different formats, where you put the number, how the street is formatted. Normalizing all of that down to a set of parameters that can be published on an API is a huge challenge.”

This means that you need robust capabilities in any third-party solution that you choose to help verify international addresses. Some of the key things to look for include:

  • How many countries does the vendor support address formats for, and does this list include all of the countries where you do business?
  • Can the application handle multiple or nested municipality formats? For example, a customer may list the same location in Brazil correctly as Rio, Rio de Janeiro, Município do Rio de Janeiro – or even the sub-municipality of Guanabara Bay.
  • Will the application handle different spellings or translations for common areas? In the address above, for example, the country may be spelled as Brazil or Brasil. Likewise, the United Kingdom may also be referred to as England, British Isles, Karalyste, Birtaniya, United Kingdom of Great Britain and Northern Ireland, or even 英国 (Chinese for the United Kingdom, literally “England Kingdom”).
  • Can these capabilities can be implemented as an API within your ordering application? Or can it process addresses externally through batch processing?

In general, cross-border fraud prevention requires a multi-pronged effort involving all of the potential stress points in an international transaction, including international address verification, email validation, credit card BIN validation, IP address verification – even name validation, so you can flag orders addressed to Vladimir Putin or Homer Simpson. These are clearly capabilities that you outsource to a vendor, unless you happen to be sitting on hundreds of millions of global addresses and their country-specific formats. The good news is that in an era of inexpensive cloud-based applications, strong fraud protection is easily implemented nowadays as part of your normal order processing strategy.

Thinking Alternatively About Place Names

Here at Service Objects we come across a lot of names, particularly the names of places. We also work with a lot of personal names, but for now I would like to focus on just place names. Whether the name is for a city, town, village, hamlet, district, region, state, prefecture, mining area, national park, theme park or what have you; chances are that the place may have one or more even alternate spellings and alternate names associated with it.

For a human fluent in English, “North Carolina” and “N. Carolina” will be considered equal, but for a computer they are not. With the use of fuzzy-matching and/or standardization we can work around seemingly trivial issues like this. Now let us suppose that you are working with a set of Japanese data and come across the same name but written in Katakana “ノースカロライナ” or Ukrainian data written in Cyrillic “Північна Кароліна” or even Thai “รัฐนอร์ทแคโรไลนา”. Well, fuzzy-matching and standardization are still our friends; we just have more fuzzy-matching and standardization rules to consider. However, we first need to ensure that we even have the data available to associate a name in a different language.

We’ve been creating a list of place names to help us tackle problems like the ones mentioned above. We currently have a list of over five million unique place names generated from a pool of approximately 11 million names. We are aggregating name data to come up with a more comprehensive list that consists of known alternates, variations in spellings, different languages and the transliterated versions for the different languages.

Here’s a quick look at what we have accomplished, so far:

  • Current list of approximately eight million place names and growing
  • Transliteration and phonetic mappings for various languages
  • Case, accent and kana sensitivity handling
  • Queryable using fuzzy-matching algorithms

We have taken some of what we have learned from our DOTS Address Validation – International service and built upon it in order to improve data beyond the realm of just address validation. When working with Phone, Email, IP, Demographic and Geo-coordinate related data we too often find that location names do not match up. Naturally this is to be expected, since different data vendors will have different standardizations and practices when it comes to naming conventions. Utilizing a comprehensive place name library will allow us to quickly perform various actions, such as cross checking multiple data sources against each other with increased flexibility and match rates.

It may not be immediately apparent how useful a place name library like this is and what kind of avenues it can open up, but expect to see new and exciting developments from us in the coming months!

C# Integration Tutorial

C# may very well be our most requested sample code.  There is good reason for that too; C# and the .NET framework are many developer’s first choice for creating a web page or any other type of application because of the versatility of the language and framework as well as the robust features that Visual Studio offers.  One of those features is the ability to consume a WSDL (Web Services Description Language) and create all the necessary classes and methods to successfully call a web service.  This makes using SOAP squeaky clean! Ok, that was the first and last SOAP pun, I promise.  Here’s what you will need for this tutorial.

Requirements

  • Visual Studio (2015 is used in this tutorial but the process should be relatively similar with any other version)
  • DOTS Web Service License Key (We are using DOTS Address Validation International for this example)
  • Some familiarity with C# and the .NET Framework. This tutorial will be pretty basic so it should be accessible even if you are a beginner.

Setting Up the Visual Studio Project

For starters, launch Visual Studio and create a new ASP.NET Web Application and choose an appropriate project name. Your screen should look similar to the following:

Click ok and then select “Empty” to create an empty web form. We will add the necessary aspx page momentarily.

But, our first step for our new project will be to add the service reference to the DOTS Address Validation International web service. To do this, right-click on “References” in the Solution Explorer and select “Add Service Reference” a pop up should appear to add the Service Reference.  Here we will add the URL to WSDL that contains the information on how the project should interact with the DOTS Address Validation International web service and we will name the Service Reference.

For reference here is the WSDL URL and here is what the pop up page should look like

WSDL: http://trial.serviceobjects.com/avi/soap.svc?wsdl

Now that we have successfully added the service reference, we can add an aspx page that will have our input form and display our results. Right click the project name and select “Add” and then select “Web Form” to add a blank web form to the project.  For our example we’ll name the form “AVIForm”.

Creating the Input Form and Code Behind

Now that our form is present, we’ll add some simple HTML and ASP elements to take in our inputs and display them to the screen after we get a response from the service. Make your ASPX page look like the following.

The above code will allow us to take the inputs send them to the code behind and the display the results in the outputGrid and InformationComponentsGrid.  We have to separate grids; one to account for the standard outputs from the service, and the other to account for the InformationComponents field to account for some variable information and data to be returned by the service.  This field can change based on the country or data available for a specific international address. Now that our input form is all set up, we’ll add the proper code behind that will display the results to the user.

We won’t look at every part of the code here, to download a .txt version of the code, click here.

One thing we like to stress to clients who are integrating our services is proper Failover Configuration.  In the unlikely event that our primary datacenters are offline or producing strange errors, we want to ensure that our clients are pointing their code to our backup datacenters so that their applications and business processes go uninterrupted.  Here is a full picture of the proper way to integrate failover into an application.

We’ve found that to ensure uninterrupted service the best practice is to have the calls to the web service nested in a try-catch block of code.  In our current setup, the backup call will hit the same data center as the primary call; but if a License Key is purchased the primary call should point to ws.serviceobjects.com and the backup call should point wsbackup.serviceobjects.com.   The screen shot below, highlights some of the primary failover logic that will allow the code to run uninterrupted.

This code occurs right after the primary call to the web service if it detects that the response from the service is null or if an Error TypeCode of “3” is returned, then the code will throw a new exception and the catch statement will call the backup web service call.

If a successful response is received from the service, the code will call a method named “ProcessValidResponse” which takes in the response from the web service and display the results into a DataGrid and then send that data grid to the ASPX page for the user to see. This method is pretty straight forward for the most part, as it simply assigns the outputs and their respective values into separate columns for the user to see.

The only part that may be mildy tricky would be the InformationComponents field that is returned from the service.  This field is an array of InformationComponent which contains two strings; one for the “Name” of the variable returned and one that indicates the “Value” of the variable returned.  For example is you pass a US address into the AVI service, one InformationComponent that can be returned will have a Name of “DPV” and a Value of “1” indicating that it is considered delivered by the USPS.  Below is an example of the XML output.

 

This array of fields allows us to add new outputs to the service over time without potentially breaking any existing client’s code.  To account for this array of information we have a brief For loop below that will loop through all the elements of InformationComponents and add their names and values to the InfoCompTable so that they can be seen by the user.

Making a Successful Call to the Service

If we go ahead and run our project, our webpage will look like the following.

Not very exciting, but it will get the job done. As an example address, we’ll use the following in France:

3 Place de la Victoire, 33000 Bordeaux, France

If this address is sent to the service you should see the following response.

As you can see, this address is considered Valid by the service and the service has a premise level resolution for this address.  The Address1-Address8 fields will also display how the address should look for mailing purposes. For this particular example we only need Address1 and Address2 but for other countries all 8 address lines may be used.  The InformationComponents field was also parsed out and the two Name and Value pairs were shown below the standard outputs from the service.

That wraps up our tutorial for DOTS AVI integration in C#.  Congratulations! You are now on your way to being a DOTS Address Validation International expert! Feel free to go and test more International addresses, and as always if you have any questions feel free to reach out to us at support@serviceobjects.com!

How to Validate International Addresses

Dealing with international addresses is no simple task. An address can often be misspelled, incorrectly formatted or simply written in a foreign language that you do not understand. The simple fact that many international addresses are foreign to us means that we are unable to recognize when something is wrong.

Take the simple word “street” for example. It is one of many commonly used words in an address. The French word for street is “rue”, in German it’s “Straße”, in Portuguese it’s “rua”, and it’s the character “路” pronounced “lu” in Chinese and so on. That’s not to mention common abbreviations either. In many cases a person will have a hard time identifying the name of a city or a street in an address and they would be unable to distinguish one from the other.

Let’s take a look at a few international examples:

China (中国)

Address:

Shanghai DPF Textile Co., Ltd.
200331
上海市普陀区武威路259号
98 -A3

Unless you are able to read Chinese you would be hard pressed to make sense of the above example. The first line is in English but it appears to simply be the name of a business. Business names are not required to validate addresses with the AVI service and it is unlikely that it would prove helpful in the validation process. To the contrary, extraneous information like this is often regarded by most systems as garbage data; however, let’s go ahead and pass the address as is to the AVI service and see how it handles it.

URL Query:url1

Here is what the query looks like when using the web service test page:

getaddressinfo

Here is the output in JSON, although the service also supports XML:json1Examining the output, we see that the AVI service fixed the order in which we entered our input values. This was done not only in the transliterated Romanized spelling of the address but also in the localized Chinese format.

Here are both versions of the address parsed from the JSON response output:

Roman Character Format

Shanghai DPF Textile Co , Ltd
98 – A3
No. 259 Wuwei Lu
Putuo Qu, Shanghai Shi
200331

Local (Chinese) Character Format

200331
上海市普陀区武威路259号
Shanghai DPF Textile Co , Ltd
98 – A3

The AVI service identified the street name, city name, postal code as well as other useful information.

 

Greece (Ελλάδα)

Address:

114 71 Αθηνα
Ασκληπιου 104
Το ΝΟΣΤΙΜΟ

Unless you can read Greek the above address would be difficult to decipher. Let’s see what the AVI service returns.

URL Query:
url2

Here is what the query looks like when using the web service test page:

getaddressinfo2

JSON Output:json2

Parsing out both of the address formats from the JSON response we get the following:

Roman Character Format:

To NOSTIMO
Asklepiou 104
114 71 Athens

Local (Greek) Character Format:

114 71 Αθηνα
Ασκληπιου 104
Το ΝΟΣΤΙΜΟ

As it turns out, “To NOSTIMO” or “Το ΝΟΣΤΙΜΟ” (in Greek), is the name of a café that resides at the address. Even though the name of the café is not technically a part of the address nor is it necessary for validation, we see that its inclusion did not impede the AVI service from performing its job.

 

Germany

Let’s see how well the AVI service handles an address when several lines of extraneous data are included.

Address: 

Accemic GmbH & Co. KG
C/O World Express (GmbH)
Gunther Meyer, Phone: +49 (0) 8033 6039790
Franzhuber Str 39
Kiefersfelden

In this example, the address is in English, but there is a mess of extraneous information included. What will the AVI service make of this example?

URL Query:url3
Here is what the query looks like when using the web service test page:
getaddressinfo3

JSON Output:json3Parsing out the address from the JSON response we get the following:

Roman Character Format:

Accemic GmbH & Co KG
C/O World Express (GmbH)
Gunther Meyer, Phone: +49 (0) 8033 6039790
Franz-Huber-Str. 39
83088 Kiefersfelden

In the above example, we see that the AVI service was able to ignore the three lines of extraneous information and identify the pertinent address information. From there the service standardized the street name, corrected the locality name and appended the missing postal code.