Identification and qualification: two things constantly confused
Software vendors serving customers in finance, real estate or insurance soon meet the wish for an AML-compliant signature. Behind it usually lies a misunderstanding running through many tenders: identification and signing are thought of as one process. In fact they are two things with different purposes, different rules and different responsible parties. Whoever separates them cleanly builds the more robust architecture and can answer auditors' questions precisely.
Identification under the German Money Laundering Act (GwG) is a duty of the so-called obliged entities, including credit and financial services institutions, insurers, estate agents or dealers in goods. They must identify their contracting parties, clarify beneficial owners and monitor business relationships. How identification may be done is regulated by law, and permitted procedures range from the ID card through electronic identity proof to video-based and other procedures under conditions. Interpretations by supervisors, such as BaFin, specify the requirements.
The qualification of a signature, by contrast, concerns the trust level under the eIDAS Regulation: a qualified electronic signature (QES) is created by a qualified trust service provider (QTSP) on the basis of a qualified certificate that presupposes verified identification. The two worlds touch because a QTSP must also identify the signer. But identification for the certificate is not automatically identification of the obliged entity under the GwG, and vice versa. Whether and under which conditions identification for one purpose can be used for the other is a legal question of the individual case.
The one hard distinction of this article is therefore: the obliged entity carries AML responsibility, the QTSP carries the qualification of the signature, and the API layer orchestrates both without taking over either responsibility. Anyone promising otherwise, such as an “AML-certified signature”, confuses terms. Neither the GwG nor the eIDAS Regulation knows a certificate for a signature API, and we claim none.
For ISVs that means: your product is usually not itself an obliged entity but a tool of your customers who are. That shifts the question. Not “is our product AML-compliant?” but “does our product support our customers in fulfilling their duties, and can they evidence it?” This wording is more honest and stronger in sales because it hits the actual role. Your customers will know the exact requirement, and you must be able to show your flow reflects it.
The link to signing arises where contracts in regulated business relationships are signed. An estate agent having a brokerage contract signed, an insurer taking an application or a financial service provider opening an account usually needs an identified person and a robust signature. Whether AES or QES fits depends on the transaction. A classification of the levels is in AES vs QES via API, the general perspective in AML, identification and QTSP for e-signature.
Roles at a glance: identity provider, QTSP partner, API layer
A clean division of roles is the most important tool in conversations with auditors and buyers. We distinguish four actors that interact in a regulated signing flow. First the obliged entity, your customer carrying the duties under the GwG. Second the identity provider, a service technically performing identification, for example by video, eID or another permitted procedure. Third the QTSP partner, who provides certificate and signature with QES. Fourth the API layer integrating these elements into your software.
The identity provider delivers a result: person identified or not, with evidence data. It works under the rules applicable to its service and bears responsibility for correct execution. Whether an identity provider is permissible for your use case is decided by the obliged entity, not the software vendor. Important for you: the evidence of the provider's result must be retained in the transaction and linkable to the signature, otherwise the chain is missing later.
The QTSP partner provides the qualified trust services with QES. Sign2x is not a QTSP. For QES we work with partners such as Sign8, and qualification arises there, under supervision and per the requirements of the regulation. For AES and SES no QTSP is required, the signing flow itself secures assignment and integrity. Which route is permissible and sensible for your transaction depends on law, contract purpose and your customer's requirements.
The API layer, that is Sign2x, brings signature levels and flows into your product. It creates transactions, binds documents and signers, controls the order of steps, returns events and ensures results from identity provider and QTSP partner remain traceable in the transaction. It is explicitly not an obliged entity, not an identity provider and not a QTSP. This clarity protects you from statements you cannot later keep and helps customers locate their own responsibility.
A matrix can make the distribution tangible. Question: who verifies identity? Answer: the identity provider, on behalf of or as directed by the obliged entity. Question: who creates the qualified signature? The QTSP partner. Question: who links results to the contract transaction? The API layer with your software. Question: who carries the AML duties? The obliged entity. Question: who is responsible for product design? You as ISV. Whoever records these five answers clearly in contract documents and security documentation has already answered most auditor questions in advance.
How the division of roles looks in the context of supply chain duties is described in DORA Article 30 and the signature audit trail. We stress here too: DORA, NIS-2 and the GwG know no certification for signature APIs. What you can deliver is evidence, traceable data on flow and responsibilities, and your architecture should be oriented exactly to that.
What ISVs orchestrate: the flow of a regulated signing path
As an ISV you orchestrate the flow from your customer's and users' perspective. A typical flow begins with the pre-check: which transaction is at hand, which level and which identification are needed? You configure these rules per transaction type and where relevant per tenant. Identification follows through the intended identity provider, its result flowing into the transaction. Then the signature runs, with QES through the partner QTSP. At the end stands completion with filing, evidence and follow-ups.
Your task is to connect these steps so no user feels the seam and no evidence is lost. That begins with the order: signing happens only after successful identification, and your system must offer no way to skip the check. It continues with waiting states: identifications take time, users interrupt, and your state model must map that. How to solve that cleanly is described in webhook state management for e-signature events.
Then there is data assignment. The identification result belongs to a concrete person and a concrete transaction. Your system should store the link between identification evidence, signing transaction and document unambiguously, with timestamps and references. What data actually sits with you and what with the identity provider or the QTSP you should decide deliberately and document, since access rights, deletion periods and retention duties depend on it.
The interface decides completion rates. Identification flows are laborious for users, and every ambiguity costs completions. Explain before the start what happens, how long it takes and what should be at hand. Keep the user in your interface instead of sending them to foreign pages as far as the identity provider allows. How to design flows without a media break is in white-label signature API without context switching.
For multi-tenant products one more point: not every customer has the same duties and preferences. An insurance broker has different requirements from a financial services provider. Your configuration should allow identification procedures, levels and texts per tenant without code changes. It should also be visible who changed a configuration when, because audits ask which rules applied at a given time. Background on tenant models is in white-label requirements for ISVs.
Finally the failure side. Identifications fail: documents are unreadable, video connections drop, users are not eligible. Your flow needs defined paths for such cases: retry, alternative procedure, manual review, abort with reason. What matters is that a failed attempt does not silently lead to a signature and that the failure appears in the log. In regulated flows documenting failure is as important as documenting success.
Data flows and hosting: where personal data goes
An AML-adjacent signing flow carries particularly sensitive data: ID data, face images, addresses, contract content. That yields a simple but central task: draw the data flows. Which data goes from the user to the identity provider? Which from the identity provider to you or the QTSP? Which comes back from the QTSP? Where are documents, evidence, logs? Such a sketch is the basis for data processing agreements, data protection impact assessment and supply chain documentation.
On hosting: Sign2x runs on the Open Sovereign Cloud (OSC) from T-Systems, a European operation under European law. That concerns our platform. Identity provider and QTSP partner are separate parties with their own locations and legal frameworks, which you should assess separately. Ask each about processing location, ownership structure and subcontractors. An explanation of why location alone is not enough is in Cloud Act vs data sovereignty.
Data economy is the most effective safeguard. Transfer only data needed for the respective step, and store evidence only as long and as far as law and contract require. The GDPR demands purpose limitation and minimisation, with special weight for ID data. Check whether you really need raw data or whether a result with a reference suffices. The less sensitive data sits with you, the smaller the attack surface and the simpler the documentation.
Retention periods in the money laundering context are rules of their own that can differ from periods for contracts. Clarify with your customers who keeps which evidence for how long, and map that in your deletion logic. A deletion run that removes evidence before the duty expires is a compliance problem, one keeping it indefinitely a data protection problem. Both can be avoided with clear classes and rules per document and evidence type.
For audit questions too: the clearer your data flows, the faster your answers. When a customer asks where ID data sits, you should not have to search but be able to point to a document. The same applies to the question who has access. We gladly support you in structuring, but responsibility for the overall documentation remains with you and your customers. A self-assessment helps to start: the Sign2x quiz sorts requirements, the help centre explains terms.
Checklist for ISVs: preparing AML-adjacent signing flows
The checklist below replaces neither legal advice nor review by your customers, but it helps prepare the architecture for typical questions.
- Record roles: document obliged entity, identity provider, QTSP partner and API layer with responsibilities, and state clearly that Sign2x is not a QTSP.
- Assign levels: set per transaction type whether SES, AES or QES applies, and have the assignment legally reviewed.
- Enforce order: ensure technically that signing is possible only after successful identification.
- Link evidence: store identification result, signing transaction and document with unique references and timestamps.
- Define failure paths: describe what happens on failed identification and log failed attempts too.
- Draw data flows: record which data goes where, where it sits and how long it is retained.
- Configure tenants: enable procedures, levels and texts per tenant with change history.
- Check partners: check status and location of identity provider and QTSP regularly and record the result.
Once you have worked through these eight points you have a robust basis for conversations with customers and auditors. Start with roles and order, because they are quickest to fix and bring the most clarity. Technical basics are in the developer hub, practical cases under use cases, more articles in the Sign2x blog. For questions on your scenario reach us via contact.
The outlook belongs here too: with the introduction of the EUDI wallet, identification routes will change. What that means for your flow depends on implementing acts and providers. We prepare the architecture but claim no productive wallet integration, as we explain in eIDAS 2.0 deadline and the EUDI wallet for SaaS. The role separation you record cleanly today eases this transition, because new channels fit the identity provider role without changing the rest.
Read up on roles and terms in the help centre
Related articles: QTSP partners for ISVs and NIS-2 evidence through the audit trail. Guidance on information security at the BSI.
Frequently asked questions
Is Sign2x AML-certified?
No, and there is no AML certificate for signature APIs. Sign2x is the API layer linking identification results and signatures traceably in the transaction. AML duties are carried by the obliged entities, your customers.
Is Sign2x a QTSP or an identity provider?
Neither. Sign2x is the API layer. For QES we work with partner QTSPs such as Sign8, and identification is performed by a designated identity provider.
Does a QES replace identification under the GwG?
Not automatically. Identification for a qualified certificate and identification under the GwG are different processes. Whether one can be used for the other purpose is a legal question of the individual case.
What must an ISV ensure technically?
That signing is possible only after successful identification, that results stay linked to transaction and document, and that failed attempts are logged too.
Where is Sign2x hosted?
On the Open Sovereign Cloud (OSC) from T-Systems. Identity provider and QTSP partner have their own locations, which you should assess separately.
