About Signicat’s implementation of Arvato Digital Identity Check
Arvato, a division of Bertelsmann based in Germany, offers information technology services and risk management solutions. Their Risk Management System offers checks to see if a customer is fraudulent and solvent by aggregating several internal and external services via a decision engine. This includes identity and address validation, solvency records and fraud checks (among others).
Signicat supports address validation through Arvato’s Digital Identity Check (DIC). This service makes it possible to check if the requested person can be identified at the specified address. Signicat’s implementation of the service requires the customer to provide a first and last name, and a valid address consisting of a street, postcal code, city, and country (only German addresses are supported by Arvato). The result of the address verification is returned as a predefined letter code.
Use cases
DIC is useful in many scenarios, for example when onboarding new customers, verifying identities and/or checking people against AML regulations (Anti Money Laundering).
Digital onboarding of a new customer
A customer wants to open a new bank account online. The bank (merchant) wants to check if the name and address match by using DIC.
- The customer uploads the identity papers.
- The merchant presents a registration form to the customer and the customer fills in name and address a.o.
- The input data is sent via Signicat to the Arvato DIC service to check if the name and address match.
- The service sends back a response to the merchant with a letter code indicating if the name and address are matched or not.
Checking a customer against fraud
A merchant wants to check if the address of a customer is valid before billing the customer. In this case, the merchant already has some customer data but wants to run an additional check using DIC to match the name and address.
- The merchant sends existing customer data via Signicat to the Arvato DIC service to check if the name and address match.
- The service sends back a response to the merchant with a letter code indicating if the name and address are matched or not.
How to integrate via Signicat
Integration with the service is done via the same API as Signicat’s ID methods. See Get started with authentication for more information. Through the single point of integration, you will get access to Signicat’s wide portfolio of integrated ID methods and other services like identity paper verification and lookups.
Data flow
This is the basic data flow when using DIC to verify a person’s address:
Step | Processor | Role | Result |
1 | Merchant | Data controller | The merchant collects the end-user’s personal information in a prepared data flow. Typically this is the full name and an address. |
2 | Signicat | Data processor |
|
3 | Arvato | Data processor |
|
4 | Signicat | Data processor |
|
5 | Merchant | Data controller | The result is presented to the merchant, either a valid or invalid address. |
How to set up the Digital Identity Check service
This section describes how to interact with the Arvato DIC service through Signicat’s API. Signicat’s Arvato service supports JSON for accessing the API.
Authentication
All requests must be authenticated by means of an OIDC access token, supplied as an Authorization header of the Bearer type. For information on how to obtain such a token, see Accessing Signicat REST services.
API
Environment | Base URL |
Beta | https://beta.signicat.com |
Preproduction | https://preprod.signicat.com |
Production | https://id.signicat.com |
Path | Verb | Scope | Content type | Input | Output |
/irpa | POST | client.arvato.irpa | application/json | DigitalIdentityCheckRequest | PersonResponse |
HTTP headers
You must set the Accept HTTP header (receiving content type) to application/json.
How to use the Digital Identity Check service
Digital Identity Check performs address validation for the supplied person to the given address.
Request
DigitalIdentityCheckRequest
Name | Type | Mandatory | Description |
person | Person | Yes | The person whose address is validated. |
Person
Name | Type | Maximum length | Mandatory | Description |
firstname | string | 100 | Yes | |
lastname | string | 100 | Yes | |
sex | string | 10 | No | Valid: ‘male’, ‘female’ |
birthday | LocalDate | 10 | No | Format: yyyy-MM-dd |
string | 100 | No | ||
address | Address | Yes | The address validated against the person. |
Address
Name | Type | Maximum length | Mandatory | Description |
street | string | 100 | Yes | |
streetNumber | string | 100 | No | |
zipcode | string | 5 | Yes | For Germany, the postal code is 5 digits. For any other 4-digit postal codes, add a zero for the first digit as a placeholder (e.g.: “03456”) |
city | string | 100 | Yes | |
country | int | 3 | Yes | The ISO-3166 code for Germany.
Valid: 276 |
Response
PersonResponse
Name | Type |
identity | IdentityResponses |
IdentityResponses
Name | Type |
dicresponse | DICResp |
DICResp
Name | Type |
DigitalIdentityCheck | DigitalIdentityCheck |
DigitalIdentityCheck
Name | Type |
featureCode | string |
featureCodeOriginal | string |
deliveryCode | string |
Understanding results
Valid request: Code 200
The request was valid and resulted in a response message.
Explanation of the feature codes in the response:
featureCode | Short description | Description |
PPB1 | Confirmation on person level by 1 data source | One data source has confirmed that the person resides at the stated address. |
PPB2 | Confirmation on person level by 2 data sources | Two data sources have confirmed that the person resides at the stated address. |
PPB3 | Confirmation on person level by 3 data sources | Three data sources have confirmed that the person resides at the stated address. |
PHB | Confirmation on household level | It is confirmed that the household resides at the stated address. |
PAB | Confirmation on address level only | The address is correct, but the household and/ or person is not verified at this address. |
PNP | Address not verifiable | The address contains structural defects (e.g. missing name) or is a fake address. |
PNZ | Person no longer living at this address | The person has resided at the stated address but has likely moved. |
PPV | Person deceased | The person is deceased. |
PPF | Address incorrect / not correctable | The address
|
PUG | Building / House unknown | The address is formally correct but the building is not known. |
Invalid request: Code 400
Code 400 means the request is invalid. In this case, the response body will provide more information. Here is an example of what the response will look like when the “firstname” property is missing and the format of “zipcode” is wrong in the request:
{
"instance": "<MERCHANT URL>/irpa",
"method": "POST",
"status": 400,
"type": "base:constraint-violation-problem",
"title": "400 Bad Request",
"violations": [{"message":"The request property 'firstname' cannot be empty"}, {"message":"The request property 'zipcode' must be a 5 digit number, prefix with 0 if only 4 digits"}]
}
Unexpected error: Code 500
Code 500 means an unexpected error occurred on the server side.
Example with values
Request
curl -X POST
-H "Content-Type: application/json"
-H "Accept: application/json"
-H "Authorization: Bearer <OIDC ACCESS TOKEN>"
-d '{
"person" : {
"firstname" : "Daria",
"lastname" : "Pepebe",
"sex" : "female",
"birthday" : "1980-01-01",
"email" : "hello@hello.de",
"address" : {
"street" : "Rheinstr.",
"streetNumber" : "46",
"zipcode" : "76532",
"city" : "Baden-Baden",
"country" : 276
}
}
}'
"<MERCHANT URL>/irpa"
Response
{
"identity":{
"dicresponse":{
"digitalIdentityCheck":{
"featureCode":"PPB",
"featureCodeOriginal":"PPB1",
"deliveryCode":"76532176046"
}
}
}
}