Security and data protection

The API moves personal data of people applying for credit. This page says what Finto does to protect it, what we ask of you, and where your security and compliance teams find the answers they will look for.

How requests are authenticated

Every request passes three checks:

1. TLS. HTTPS only (TLS 1.2 or newer), with HSTS. There is no plain HTTP. The partner host is served directly by Finto's server, not through a CDN.
2. IP allow-list. In live, the request must come from an address or range on your list. Entries may be single addresses or ranges up to /24 (IPv4) or /48 (IPv6). A request from an unknown address is refused before the key is looked at, so the answer says nothing about whether a key is valid.
3. API key. Authorization: Bearer fnt_live_... (live) or fnt_test_... (sandbox). A key works only in its own environment.

Mutual TLS (client certificates) is available on request for live connections, in addition to the checks above; Finto then pins your certificate.

API keys

• Issued by Finto, delivered to your named technical contact through a one-time link that works once and expires. Finto stores only a one-way hash and never sees the key again; a lost key cannot be recovered, only replaced. Keys end with a checksum so secret scanners can recognise them.
• Expire after at most 12 months (expiresAt in GET /v1/me). Finto reminds your technical contact 30 days before.
• Two active keys at a time, so you rotate without downtime: get a new key, deploy it, then revoke the old one.
• Revoke at any hour yourself: POST /v1/api-key/revoke with the key revokes it at once. Do this the moment you suspect a leak, then ask Finto for a new key. The access log shows every request made with the old one.
• Keep keys in a secret manager, never in source code, URLs or logs.

Webhook secrets

• Every webhook is signed with your secret (whsec_...), see webhooks.md. Verify the signature before you trust the body.
• The secret is delivered like a key, through its own one-time link. Finto stores it encrypted, because it needs it to sign.
• Rotation: Finto issues a new secret and signs with both for at least 24 hours, so you can deploy the new one without missing events.

Your webhook endpoint

• HTTPS on port 443, a public host name, a certificate from a public CA.
• Finto resolves the host on every delivery and refuses private, internal and reserved addresses, so the endpoint cannot be pointed at internal systems. Redirects are not followed.
• Finto sends from the fixed addresses in webhookSourceIps; changes are announced 30 days ahead.

What you can see

• Only applications sent to you. Being in the creditor table is required but not enough: the application must have been sent to you, you must be active, and the client must not have withdrawn. This is checked on every request, not only in lists; anything else returns the same 404.
• Only documents meant for you: the signed application, what the client provided for you, and your own uploads. Never another lender's documents or Finto's internal files.
• Only your own decisions and uploads, never those of other lenders.
• No personal data in events (webhooks and the feed carry identifiers only), none in URLs or query parameters, none in lists.
• Responses with personal data carry Cache-Control: no-store.

Access windows

Situation	Access to the application
While you work on it (open, or your offer chosen)	Full
After your first final decision (rejected, cancelled, disbursed, terminated) or after it closes for you	Full for 14 more days, then 410; a newer version opens it again. Your own decisions stay readable, and reports about the agreement are still accepted
Client withdrew consent	None from that moment (410)

You are expected to keep what you need in your own systems, under your own legal basis and retention rules.

Protecting the client from abuse

• Links: your offer.continueUrl must be on a host registered with Finto (continueUrlHosts in GET /v1/me), https, without another port, user name or IP address. Finto shows the client the host before sending them there. Text shown to the client (offer.conditions, requirements[].description) may not contain links at all.
• Text: control characters and invisible formatting characters are rejected in everything you send.
• Changed terms: if you change the terms of an offer after the client chose it, the choice ends and the client chooses again, so the client always agrees to the terms that apply.
• Closing other lenders: an agreement reported without the client's choice through Finto closes the other lenders' applications only after Finto staff confirm it with the client.

Logging on Finto's side

Every read of an application, every document download and every decision is recorded with the key, the IP address, the request id and the time. Refused requests (401, 403, 404, 410) are recorded too, and unusual patterns (many unknown ids, a valid key from a wrong address) alert Finto staff. Finto staff see in the application's history when you fetched it and its documents. The logs serve audits and data protection requests.

Separate sandbox

The sandbox runs separately from live, with its own database, files, keys and secrets, and its own network. It holds generated data only: no copy of live data ever goes there. Personal codes in the sandbox come from public Smart-ID and Mobile-ID test identities, so they cannot match a real person.

What we ask of you

As a lender you receive the client's data as a separate data controller, under your agreements with Finto. In particular:

• Protect the key and the secret as you protect your own credentials; restrict who can read them, and revoke a key you suspect.
• Verify webhook signatures, and allow only Finto's source addresses.
• Use the data only to assess this application and for what the client agreed to in the signed application.
• On application.withdrawn, stop processing the data for this application, as described in lifecycle.md.
• Do not log personal data from responses in plain text, and keep the signed PDF where your other credit documents live.
• Tell Finto without delay about any incident that may affect data received through the API, and about changes of your outbound IP addresses before you make them.

For your security and compliance review

Answered on this site:

Question	Where
What data is sent, and what is not	data.md
What the client signs and consents to	signed-application.md
Authentication, keys, rotation, revocation	This page
Webhook security	webhooks.md
Consent withdrawal	lifecycle.md
Change policy	changelog.md

Answered in your onboarding pack and agreements, because they are contractual: where the service is hosted and Finto's sub-processors; how long Finto keeps applications, decisions and logs; Finto's deadline for notifying you of an incident; availability targets and maintenance windows; security assessments; contacts for integration questions, key issues and incidents, and their hours.

Quote the Finto-Request-Id of the requests concerned whenever you contact Finto.