Data protection¶
Most zzp'ers are natural persons, which puts this integration inside both the AVG and the EU AI Act. The obligations split cleanly, and most of them sit with Noja.
Who is responsible for what¶
| Obligation | Owner | How it is met |
|---|---|---|
| Controller for your own user data | Partner | Existing relationship, unchanged by this integration |
| Collecting opt-in consent | Partner or Noja | Captured in-product and sent as the consent object, or recorded by Noja when the client signs |
| Controller for the financing assessment | Noja | Separate purpose, separate legal basis, from the point data reaches us |
| Creditworthiness decisioning | Noja | Human-in-the-loop review on every decision, with a full audit trail |
| AI Act high-risk documentation | Noja | Model documentation, logging, and human oversight are Noja's to maintain |
| Right of access | Shared | The partner forwards the request; Noja returns what it holds |
| Right to erasure | Shared | The partner forwards the request; Noja erases what regulation does not require retaining |
The partner does not become a processor for Noja, and Noja does not become a processor for the partner. Each is an independent controller for its own purpose, with a data-sharing agreement governing the handover. That is the arrangement the DPA reflects.
The consent object¶
The evidence that a user opted in, and what an auditor will ask for.
It is optional on client creation, but financial data is refused until consent exists. There are two ways it gets recorded:
- You send it. You captured the opt-in in your own product and pass the object below.
- Noja records it. The client signed Noja's financing agreement through the hosted onboarding flow, which covers the same permission. Noja sets the record itself and you never send the object.
Until one of those has happened, POST /invoices returns 403 consent_required.
{
"obtainedAt": "2026-09-14T09:31:04Z",
"method": "in_product_checkbox",
"evidenceRef": "ptr-consent-4471a9",
"scope": ["invoice_data", "company_data", "financing_assessment"]
}
| Field | Notes |
|---|---|
obtainedAt |
When the user opted in. Must precede the API call. |
source |
Read-only. partner when you sent it, signing when Noja recorded it at signature |
method |
in_product_checkbox, signed_agreement, or verbal_recorded |
evidenceRef |
A pointer into your own records |
scope |
What the user agreed to share. Omitting a scope withholds that data category. |
evidenceRef stays a pointer. We never ask for the consent artefact itself — only for something that lets you produce it on request.
Consent must be specific
A general acceptance of the partner's own terms is not consent to share invoice data with a financing provider. The opt-in has to name Noja and name the purpose. This is the single most likely finding in an AVG audit of this integration.
Automated decision-making¶
Financing decisions are scored automatically, then reviewed by a person before anything becomes final. Under Article 22 AVG a user has the right to contest a decision and to obtain human review — a right that is satisfied by design here rather than on request, because a human already reviews every decision.
The EU AI Act classifies creditworthiness assessment of natural persons as high-risk. The resulting obligations — model documentation, event logging, accuracy monitoring, human oversight, and transparency to the affected person — sit with Noja as the provider and deployer of that system. Nothing in this API asks a partner to take on an AI Act obligation.
What this means practically for you:
- You may tell users their invoice is being assessed. You should not present the outcome as instantaneous or purely automatic.
- Decline reasons returned through the API are deliberately coarse. Detailed grounds for a credit refusal go to the applicant directly, not through a partner channel.
- If a user contests a decision, forward them to Noja. Do not attempt to explain or re-run the assessment.
Purpose limitation¶
Invoice and company data sent here is used for financing assessment, decisioning, and servicing.
It is not used to train general-purpose models, not sold, and not shared beyond the credit bureau and signing provider named in the DPA. Payables are used solely to complete the cash-flow picture behind a credit limit — never marketed against, and never shared with the suppliers named on them.
Data residency¶
All data is stored and processed inside the EU. The credit bureau and signing provider are both EU-established. No transfer to a third country takes place under this integration, so no transfer mechanism is required.
Retention¶
| Data | Retained |
|---|---|
| Financing records and decisions | 7 years, under Dutch financial record-keeping rules |
| Clients that never complete onboarding | Deleted after 12 months of inactivity |
| Invoice history for active clients | Duration of the relationship, then 7 years |
| Webhook event payloads | 7 days |
| API request logs | 90 days |
Security¶
- TLS 1.2 or higher on every connection. Plain HTTP is refused, not redirected.
- Credentials are rotatable from the partner console without downtime — old and new tokens overlap for 24 hours.
- Webhook payloads are signed. Verify them, and treat an unsigned or stale request as hostile.
- Report a suspected credential compromise to
security@noja.fi. Rotation is immediate; there is no need to wait for a reply.