Skip to main content

Referral Partners: Data privacy and DPA considerations

This article explains how data privacy works within the Debitura platform, what Data Processing Agreements (DPAs) are, and what you should know as a referral partner about the handling of personal data across the collection lifecycle.

Updated over a week ago

What is a Data Processing Agreement (DPA)?

A Data Processing Agreement is a legally binding contract between a data controller and a data processor. It governs how personal data is processed and ensures compliance with GDPR Article 28. In the Debitura ecosystem, your clients (creditors) act as the data controller, and Debitura acts as the data processor. This means creditors determine the purpose of data processing (collecting outstanding debts), while Debitura processes debtor personal data on their behalf and under their instructions.

For a detailed explanation of GDPR roles and responsibilities, see Data protection and DPA fundamentals.

Why this matters for referral partners

As a referral partner, you integrate with Debitura through dedicated APIs and may submit cases on behalf of your clients. When your integration creates cases or accesses case data through bearer tokens, personal data (debtor names, contact details, addresses, financial claim details, and supporting documents) flows through the platform. Understanding how this data is protected helps you inform your clients, maintain trust, and align with your own compliance obligations.

If your clients are based in the EU or handle personal data of EU residents, they must have a signed DPA with Debitura before personal data can be processed. The DPA is not part of the API-driven referral onboarding flow. Instead, Debitura provides a self-service DPA wizard that creditors complete by logging into the Debitura platform directly. This wizard covers company data confirmation, authority attestation, digital signing, and adding a privacy policy snippet to the creditor’s website as required by GDPR Article 13. There are no API endpoints for the DPA process.

GDPR roles in the referral model

The referral partner model involves several actors with distinct data responsibilities:

  • Creditor (your client): Data controller. Determines the purpose of processing. If EU-based or handling EU residents’ data, responsible for having a DPA with Debitura.

  • Debitura: Data processor. Processes debtor personal data on the creditor's instructions. Does not use debtor data for its own purposes.

  • Collection partner: Performs actual debt recovery work. Operates under the legal framework established by the contracts and signatures framework.

  • Referral partner (you): Technology platform that embeds Debitura's capabilities. Accesses case data through scoped, time-limited bearer tokens issued via the Referral Partner API.

How your clients sign the DPA

The DPA is not part of the API-driven referral onboarding flow. If your client is EU-based or handles EU residents’ data, they complete the DPA separately by logging into the Debitura platform. The DPA wizard is a five-step process available to creditor admin users:

  1. Review and confirm company data (creates an immutable snapshot of company details at signing time)

  2. Review the DPA document and attest to signing authority

  3. Provide a digital signature

  4. Add a GDPR Article 13 privacy policy snippet to their website

  5. Final confirmation

The signed DPA is stored as a PDF with a SHA256 integrity hash. Every action in the DPA process is logged in an audit trail capturing event type, user identity, IP address, and timestamp.

Bearer token security and data access

When your integration accesses the Customer API on behalf of a client, it uses short-lived bearer tokens (JWT) with a 30-minute expiry. These tokens are scoped to a specific client and include audit metadata:

  • Tokens are signed using HMAC-SHA256 and transmitted over HTTPS only

  • Each token issuance is logged with IP address and user agent for anomaly detection

  • Tokens can be revoked in the event of a security incident

  • No refresh mechanism exists; a new token must be requested after expiry

For more on how your integration connects to Debitura, see API and integration overview.

Data retention and deletion

Debitura follows a two-stage approach to data lifecycle management:

Data type

Retention period

Active account and case data

While the creditor's account is active

Soft-deleted data (after account closure)

6 months (recovery window before permanent removal)

Audit logs

7 years (legal requirement), then archived for up to 10 years total

After account closure, data is soft-deleted and remains inaccessible but stored for up to 6 months. A scheduled cleanup process then permanently removes the data. Audit logs are retained longer to meet legal requirements for accounting records and are pseudonymised after the 7-year retention period.

GDPR rights and requests

Your clients, as data controllers, are responsible for responding to GDPR requests from debtors. Debitura supports these obligations:

  • Data Subject Access Requests (DSAR): Creditors can contact [email protected] to request an export of debtor data held by Debitura.

  • Erasure requests (GDPR Article 17): Creditors can contact [email protected]. Data tied to legal obligations (audit logs, financial records) may be exempt under GDPR Article 17(3).

  • GDPR requests must be acknowledged within 30 days.

Audit trails

Debitura maintains comprehensive audit trails for all data processing activities, covering user account management, access grants and revocations, role changes, and configuration changes. These records fulfil GDPR Article 30 requirements. Audit trail data is immutable (cannot be modified after creation), restricted to authorised roles, and retained for 7 years.

What to expect

  • EU-based clients handle the DPA directly with Debitura. The DPA is completed through the Debitura platform (not via API). You do not need to facilitate the DPA signing, but EU-based clients who have not completed the DPA cannot have their cases processed.

  • Your API access is scoped and audited. Bearer tokens limit access to a specific client's data for a short time window. All token usage is logged.

  • Data is not shared beyond the collection workflow. Debitura processes debtor data solely for debt collection on the creditor's instructions. Debitura does not use debtor data for its own purposes.

  • Future Partner-Debitura DPAs. The DPA architecture supports agreements between partners and Debitura. If formal referral partner DPA requirements are introduced, this article will be updated.

Related resources

Developer Docs: Developers: For technical details on bearer token authentication and API integration, see Developer Docs: Referral Partner API.

Did this answer your question?