Security
What actually protects your money.
Not a list of badges. These are the controls in the product as built — how sessions are held, how money movement is authorised, and what the browser is allowed to do.
Our approach
Assume the attacker gets one thing right.
Security that depends on nothing going wrong is not security. The design assumption here is that any single control will eventually fail — a password will leak, a script will get injected, a device will be stolen — and that no single failure should be enough to move someone's money.
That is why authentication and authorisation are separate. A stolen session gets an attacker a view; it does not get them a transfer, because moving funds needs a transaction PIN they do not have. It is also why tokens sit in HttpOnly cookies rather than localStorage: script running on the page cannot read them even if it gets there.
Below is what is implemented, stated plainly. Where something is a third-party attestation rather than a property of the system, we say so instead of implying we hold it.
Controls
What is in the product today.
Sessions in HttpOnly cookies
Access and refresh tokens live in HttpOnly cookies, never in localStorage. JavaScript on the page cannot read them, so a script injection cannot walk away with your session.
Token rotation on refresh
An expired session refreshes transparently and the backend rotates both cookies. A captured token has a short useful life and is invalidated once rotated.
Separate transaction PIN
Moving money needs a PIN that is distinct from your password. Holding a valid session is not sufficient authority to move funds out of an account.
Active session detection
If your account is already signed in elsewhere, login tells you the device, type, IP address and start time — so an unexpected session is visible rather than silent.
Identity verification
Accounts are verified against BVN or NIN records before they can hold a balance, with tiered limits. This is what stops an account being opened in your name.
Fraud screening
Transactions are screened for fraud signals, and flagged activity is surfaced in the dashboard rather than resolved invisibly behind the scenes.
Enforced password strength
Passwords require at least 8 characters with upper and lower case, a digit and a symbol. The rules are shown as you type rather than rejected after the fact.
No account enumeration
Password reset returns the same response whether or not an account exists for that address, so the endpoint cannot be used to discover who has an account.
Single-use reset links
Password reset links are short-lived and can only be used once, so a link that leaks from an inbox after use is already worthless.
In the browser
The policy every page is served with.
These headers are applied to every route. You can verify them yourself in your browser's network inspector — no trust required.
| Header | Value | What it prevents |
|---|---|---|
| Content-Security-Policy | Restricts script, style, image, font and connection origins | Limits what a page can execute or talk to, which is the main defence against injected script. |
| X-Frame-Options | DENY | The app cannot be framed, which prevents clickjacking a logged-in session. |
| frame-ancestors | 'none' | The modern equivalent of the above, enforced by CSP as well as the legacy header. |
| X-Content-Type-Options | nosniff | Stops the browser guessing content types and executing something as script. |
| Referrer-Policy | strict-origin-when-cross-origin | Account identifiers in a URL are not leaked to third-party sites in the referrer. |
| Permissions-Policy | camera=(), microphone=(), geolocation=() | The app cannot request camera, microphone or location, even if a dependency tried. |
| form-action / base-uri | 'self' | A form cannot be redirected to post your credentials to another origin. |
Disclosure
Found something? Tell us.
Good-faith security research makes this safer for everyone. Here is what we ask, and what you can expect from us.
- Report to
- security@northpoletradelink.net
- Please include
- Steps to reproduce, affected endpoint, and impact
- Please avoid
- Accessing other users' data, destroying data, or disrupting service
- Please don't
- Open a public issue or disclose before we have had a chance to fix it
- Our commitment
- We will not pursue action against research that stays within the above
NorthPole does not currently run a paid bug bounty. Reports are still read and acted on, and we will credit you if you would like to be credited.
Your part
Four things that matter more than the rest.
Use a unique password
A password reused from another service is only as safe as that service's worst day. A password manager removes the trade-off entirely.
Set a transaction PIN
Do it before your first transfer, and do not use a PIN that appears on your card or your date of birth.
Never share a one-time code
No NorthPole employee will ever ask for your password, PIN or a one-time code. Anyone who does is attempting fraud.
Check unexpected sessions
If login reports an active session on a device you do not recognise, change your password and write to support immediately.
Think your account has been accessed by someone else?
Change your password immediately, then write to support@northpoletradelink.net. NorthPole will never ask you for your password, PIN or a one-time code — by phone, email or SMS.
Security questions.
Does NorthPole hold SOC 2 or PCI DSS certification?
Certification status is not published on this page, because a certification claim is only meaningful with the report behind it. If you need our current attestation status for procurement or a vendor review, write to security and we will tell you exactly where we stand and share what we can under NDA.
Where are my funds actually held?
With licensed partners, not with NorthPole. NorthPole is a technology company rather than a bank, so regulated activities including deposit-holding and card issuing sit with partners who are licensed to perform them.
Why does a valid login not let me move money?
Because authentication and authorisation are separated deliberately. Signing in proves who you are; a transaction PIN authorises money leaving the account. Someone who obtains a session still cannot move funds.
How do I report a vulnerability?
Write to security@northpoletradelink.net with enough detail to reproduce it. Please report privately rather than opening a public issue, and give us a reasonable window to fix it before disclosing. We will not pursue action against good-faith research that avoids privacy violations, data destruction and service disruption.
Is my card data stored by NorthPole?
Card processing is handled through our payment partners' infrastructure. If you are building on NorthPole Pay, the hosted checkout keeps card entry off your own systems entirely, which is the simplest way to reduce your own compliance surface.
What happens if you find a breach?
Affected users are notified along with regulators where notification is required, and we say what happened, what data was involved and what we changed. We would rather publish an uncomfortable post-mortem than a vague statement.
Still have a question? Talk to us.
Build on infrastructure that takes this seriously.
Explore test mode, read how verification works, and see the controls for yourself.