Security & Compliance

Regulatory status & approach

NectPay Ltd intends to seek authorisation as a Payment Institution with the UK Financial Conduct Authority (FCA); this application has not yet been submitted. Until authorisation is granted, NectPay does not hold client funds at any point and operates exclusively through regulated partner institutions for all money movement. NectPay functions as a technology and compliance layer only — the regulated partner institution (not NectPay) is the party of record for settlement.

We have chosen to pursue UK authorisation as our primary regulatory base because it gives enterprise clients in the UK and EU a familiar, well-understood compliance framework to evaluate us against, and because it is a prerequisite for the banking and payment partnerships NectPay depends on.

As NectPay expands into individual African markets, we will pursue local licensing or regulated partnership arrangements (e.g. with a licensed Payment Service Provider) in each jurisdiction, consistent with that country's central bank requirements. We do not claim authorisation we do not yet hold, in any jurisdiction.

Data protection & encryption

NectPay is designed around the principle that recipient and transaction data should be encrypted at every stage — in transit and at rest — and accessible only to the systems and people who need it to process a payment.

• In transit: All API traffic is encrypted using TLS 1.3. Earlier TLS versions are not supported.
• At rest: Transaction records, recipient identification data, and compliance screening results are encrypted using AES-256.
• Data minimisation: NectPay's API is designed to request only the data required to satisfy the destination jurisdiction's compliance rules for a given payout — not a standard maximal data set collected regardless of need.
• Data residency: Client and transaction data is processed and stored in UK/EU data centres. Where a local processing requirement exists in a destination African market, data handling is scoped to comply with that requirement specifically.
• Retention: Transaction and compliance records are retained for the period required by applicable financial recordkeeping regulation (typically 5 years), and no longer than necessary beyond that for active disputes or investigations.

How the compliance engine works

Every payout NectPay processes passes through jurisdiction-specific compliance checks before any payment rail is contacted. This is a deliberate architectural choice: compliance failures are caught at initiation, not mid-transfer.

• Documentation checks: Each destination market has its own requirements (recipient identification, purpose codes, enhanced due diligence thresholds). A payout that doesn't meet them is stopped before processing, with a clear reason returned to the sender.
• Sanctions & PEP screening: Recipients are screened against sanctions and politically-exposed-person watchlists before funds are released. A potential match triggers manual review rather than automatic clearance or automatic rejection.
• Jurisdiction-specific rules: Compliance thresholds and requirements are configured per destination country and updated as local regulation changes — they are not a single global ruleset applied uniformly.

You can see this logic running (against simulated data) in the live developer demo on our homepage.

Money movement & safeguarding

NectPay does not hold client funds at any stage. All funds are held and settled by regulated partner institutions (currently Thunes, pending integration). NectPay operates as a technology layer: it initiates and instructs payment flows but never takes custody of money in transit. This means:

• Client funds are kept segregated from NectPay's own operating funds at all times.
• Settlement to African payment rails (banks, mobile money operators, agent networks, digital asset rails) is executed through licensed partners in each market.
• NectPay does not commingle client funds with operational cash, and does not use client funds for any purpose other than completing the payout they were submitted for.

Access control & infrastructure

• Principle of least privilege: Internal access to production systems and transaction data is role-based and limited to what a given function requires.
• Multi-factor authentication: Required for all internal access to production infrastructure and client data systems.
• Audit logging: All access to transaction and recipient data is logged and attributable to an individual user or service account.
• Infrastructure: Hosted on cloud infrastructure with independent SOC 2 / ISO 27001 certification at the hosting layer. NectPay is pursuing Cyber Essentials certification (UK NCSC) as a near-term milestone, with SOC 2 Type II planned for Year 2 once backend infrastructure is established.

Incident response

NectPay maintains an incident response plan covering detection, containment, client notification, and post-incident review for any security or data event. In the event of a data breach affecting client or recipient information, affected parties will be notified in line with UK GDPR requirements (without undue delay, and within 72 hours to the ICO where required).

A public status page tracking rail and system uptime is planned as part of our post-launch roadmap.

Sub-processors & partners

NectPay relies on a small number of sub-processors and regulated partners to deliver its service — for example, cloud hosting providers, sanctions screening providers, and licensed payment institutions in each market. A current list of material sub-processors will be published here ahead of general availability, with advance notice of any additions.

Reporting a security concern

If you believe you've identified a security vulnerability in NectPay's systems, please report it to security@nectpay.com. We are committed to investigating credible reports promptly and will not pursue legal action against good-faith security researchers who report responsibly and do not access or exfiltrate client data.