Concedus using Reliance
Concedus, as a regulated financial institution, may also operate in conjunction with Reliance for specific onboarding and compliance processes.
This chapter applies only if Reliance is enabled. In this case, the content of this chapter replaces the standard article “Send Customer Record” in its entirety.
Reliance introduces additional regulatory and compliance requirements. Therefore, when using Reliance, further customer-related data must be provided, and the request/response structures differ in certain aspects from the standard process. This article outlines all required extensions and adjustments.

Key Differences with Reliance
Extended Data Requirements
Reliance mandates additional information fields (e.g., AML-relevant data, extended identification attributes, professional client classification).
These fields are described in detail in the subsequent sections of this chapter.
Data Validation Rules
Validation is stricter under Reliance due to the regulated nature of Concedus.
Mandatory fields and structural constraints must be adhered to exactly as documented.
API Behavior
Endpoints remain structurally identical (/v1/customers etc.), but the payload schema is extended.
Clients must ensure they send the Reliance-compliant payload if Concedus is configured to operate in Reliance mode.
API Method
Customers and companies are imported with the same endpoint.
To distinguish these two types of records, set the field customers.person.type as follows:
"0" = customer (natural person)
Import customer as individual
POST https://demo2.api.concedus.com/v2/compliance/reliance/contacts
Headers
Content-Type*
String
application/json or application/zip
Authorization*
String
Bearer token
Request Body
{
"identLinks": []
}{
"code": "400",
"info": "Error progressing File",
"reason": "<individual Error description>"
}Data Format
ZIP must be sent as attachments are to be transferred as well.
The customer JSON must be placed together with all referenced attachments inside a ZIP archive.
This ZIP file is then sent as a binary payload via POST (REST) to the designated endpoint.
The JSON file should be named main.json inside the archive.
Every file listed under the events[].file property must also be included in the ZIP.
No additional files are allowed in the ZIP; only files explicitly referenced in the events array may be present.
The Content-Type header must be set to application/zip.
This ensures that the payload is self-contained, auditable, and consistent between the metadata (main.json) and the actual attached documents.
JSON structure
Structure of data
Person
KYC-relevant fields are indicated in red
type
number
required
0 (customer)
precheckPep
string (True/False)
required
Early flag indicating potential PEP hit (client-side precheck).
salutation
string
optional
Mr. = "Herr"
Mrs. = "Frau"
title
string
optional
Title like "Dr." , "Prof." or "Prof. Dr."
foreName
string
required
All forenames of customer
surName
string
required
Surname of customer
street
string
required
Street name and number
zip
string
required
Postal code
city
string
required
City
birthDate
ISO 8601 timestamp
required
Birthdate (18+)
birthPlace
string
required
Birthplace
birthCountry
string
optional
Birth country code
nationality
string
required
Nationality (country code) eg. DE,EN,FR..
furtherNationalities
array[string]
optional
List of further Nationalities (country code)
phonePriv
array[string]
optional
List of private phone numbers
email
string
optional
Business e-mail address
mobile
string
optional
Mobile phone number
customFields[].name
string
required
"KYC" (to define the KYC Provider behind Reliance)
ID Document
The idDocument section contains all relevant identification document details, such as type, issuing country, document number, and validity dates.
It ensures that the provided customer identity can be verified against official sources and is mandatory for KYC compliance.
.docType
enum (PASSPORT,IDCARD)
required
Document type (e.g., PASSPORT) used for KYC
issueCountry
enum (ISO 3166-1 alpha-2)
required
Document issuing country.
documentNumber
string
required
Document number (passport/ID).
additionalNumber
string
required if available
Additional document number (if any).
issueDate
ISO 8601 timestamp
required
Issue date
expireDate
ISO 8601 timestamp
required
Expiry date
Verification
The verification section records the method, vendor, and timestamps of the performed identity verification (e.g., VideoIdent via Sumsub).
It provides an audit trail showing when and how the identity was confirmed by an external KYC provider.
verificationMethod
enum(VIDEO,QES,BANK)
required
Verification method (VIDEO/…).
approveTime
ISO 8601 timestamp
required
Time when verification was approved.
updateTime
ISO 8601 timestamp
required
Last update of verification status.
vendor
enum(SUMSUB,IDNOW,WEBID,...)
required
KYC provider (e.g., SUMSUB/IDNOW).
Compliance
The compliance section contains the results of PEP and sanctions screenings, including timestamps, hits, and source lists.
This ensures that every customer is checked against relevant regulatory databases and that any potential risk is documented.
pep
boolean
required
PEP status (politically exposed person)
pepChecked
ISO 8601 timestamp
required
Time of PEP check
pepHit
string / null
if match
Reason or list for PEP hit
pepListNames
array
if match
List(s), in which the customer is listed as PEP
sanction
boolean
required
Sanction list hit (yes/no)
sanctionChecked
ISO 8601 timestamp
required
Time of sanction list check
sanctionHit
string / null
if match
Reason or list for sanction hit
sanctionListNames
array
if match
List(s) in which the customer is listed as sanctioned
Professional Client Classification
The professional section defines whether a customer is treated as a professional client under MiFID II/WpHG.
It includes criteria for regulated/unregulated companies, private opt-up clients, as well as declarations and a formal signature confirming classification.
If professional is true, all fields are required to be filled
isProfessional
boolean
required
Flag whether customer is classified as professional
classification.company_based.regulated.CO-1A…CO-1G
boolean
Flags for regulated company types
classification.company_based.unregulated_with_criteria.CO-2A…CO-2C
boolean
Flags for unregulated companies with criteria
classification.private_client.PC-1A…PC-1C
boolean
Flags for private customers with criteria
declarations.confirmationCorrectInfo
boolean
Confirmation that the information is correct
declarations.agreeToClassification
boolean
Consent to classification
signature.place
string
Place of signature
signature.date
ISO date (YYYY-MM-DD)
Date of signature
signature.signatureField
ISO 8601 timestamp
Signature time
meta.formVersion
string
Version of the classification form
Custom Fields
Provides flexible key/value pairs to attach integration-specific metadata (e.g., which KYC provider was used). This allows customization without changing the core schema.
Investment Surveys
standard_questionnaire.question
Array
required
Events / Files / Attachements
The events array allows platforms to transmit documents and attachments as part of the customer import.
This is typically used for KYC proof documents, such as subscription forms, declarations, or signed agreements.
Each entry in events represents a single file reference, enriched with metadata for auditability.
Bank Accounts
accountHolder
string
depends on usecase
Surname, Forename
bic
string
depends on usecase
Bank identifier code
iban
string
depends on usecase
International bank account number
bank
string
depends on usecase
Name of the bank
country
string
depends on usecase
Country code
currency
string
depends on usecase
Currency code
Last updated