A link request is a page your customer opens to connect their bank account, or to share their transactions once. Before they enter their online banking details, that page shows your name, logo and website, and tells them exactly what you will receive and what Banklink keeps.
Because customers trust that page with their banking login, Banklink verifies every organisation before it can send live link requests. This guide lists what you need, how the automatic checks work, and what to do if they can't pass.
What you need
Have these ready before you start:
| Requirement | Why |
|---|---|
| Display name and registered company name | Customers see who is asking. The registered name is the responsible party under POPIA. |
| A website on a domain you control | Shown to customers as proof of who you are. You prove you control it. |
| A privacy policy on that domain that mentions Banklink | POPIA requires that customers are told an operator handles their data for you. |
| A privacy contact email | Where customers ask about their data or withdraw consent. |
| One line on why you need bank data | Shown on the consent screen, for example "To assess your loan application". |
| Admin access to your Banklink workspace | Only admins can edit the profile and run verification. |
A logo (square PNG, JPEG or WebP, up to 256 KB) and a redirect URL are optional.
Step 1: complete your link profile
In the dashboard, open Link Requests → Branding & verification and fill in the profile. Two rules apply to the URLs:
- The privacy policy URL and redirect URL must be
httpsand on your website domain, or one of its subdomains.https://legal.acme.co.za/privacyis fine foracme.co.za;https://acme.notion.site/privacyis not. - Public mail domains such as gmail.com can't be used as a website domain.
Step 2: prove you control the domain
Pick one of two methods. Both use a token shown on the Branding & verification tab.
DNS TXT record. Add a TXT record with the name _banklink-verification.yourdomain.co.za and the value banklink-verification=<your token>. Most DNS providers apply changes within an hour.
Verification file. Publish a plain-text file at https://yourdomain.co.za/.well-known/banklink-verification.txt that contains banklink-verification=<your token>. Redirects are followed only within your domain.
Step 3: disclose Banklink in your privacy policy
Your customers must be told that Banklink retrieves and processes their bank data on your behalf. The Branding & verification tab gives you a clause to copy, filled in with your purpose and contact email. Adapt it with your legal adviser and publish it on your privacy policy page.
The automatic check looks for the word "Banklink" on that page. If your privacy policy only renders with JavaScript, the check can't read it: request a manual review instead.
Step 4: run the checks
Click Run checks. Banklink checks that:
- every required profile field is filled in;
- the DNS record or verification file carries your token;
https://yourdomain.co.zaloads;- your privacy policy loads and mentions Banklink;
- your redirect URL, if set, is on your domain.
When all five pass, you are verified straight away and can create link requests from the dashboard or the API. Each failed check says what was wrong, so you can fix it and run the checks again.
If the checks can't pass: request a review
Click Request review and tell us why. Common reasons are no access to DNS, or a privacy page built entirely in JavaScript. Banklink reviews requests by hand, usually within 1–2 business days, and emails your workspace admins with the outcome. If we decline, the reason is shown on the Branding & verification tab.
What customers see
Before entering any login details, your customer sees:
- your logo, display name and verified domain, marked as verified by Banklink;
- why you need the data, and exactly what you receive: account number and transactions for the date range you set;
- how their data is handled, which depends on the request type;
- links to your privacy policy and Banklink's, your privacy contact, and their right to complain to the Information Regulator.
The handling text depends on the request type:
| Request type | Login details | Transactions |
|---|---|---|
| Link request (ongoing) | Stored by Banklink, encrypted, so you can fetch new transactions later | Kept by Banklink only if you choose to save them in your dashboard |
| Access request (one-time) | Used once, not stored | Sent to your webhook or email, not kept by Banklink |
After they finish or cancel, customers go back to your redirect URL with banklink_status (success, cancelled, expired, revoked or already_completed) and banklink_reference added as query parameters.
Webhooks must be on your domain and verified by you
For live link and access requests, webhook URLs must be https on your verified domain. Every webhook Banklink sends, including those from Pulses, carries a Banklink-Signature header:
Banklink-Signature: t=1790000000,v1=5257a869e7ecebeda32affa62cdca3fa51cad7e77a0e56ff536d0ce8e108d8bd
v1 is an HMAC-SHA256 of {t}.{raw request body}, keyed with your webhook signing secret from Settings → Webhook signing. Recompute it from the raw body, compare in constant time, and reject anything older than five minutes. The Node and Python SDKs do this for you:
import { constructWebhookEvent } from '@banklink/sdk';
const event = constructWebhookEvent(rawBody, req.headers['banklink-signature'], process.env.BANKLINK_WEBHOOK_SECRET);
from banklink import construct_event
event = construct_event(request.get_data(), request.headers.get("Banklink-Signature"), WEBHOOK_SECRET)
When you rotate the secret, the old one keeps signing for 24 hours, so the header carries two v1 values during the switch.