PCI DSS v4.0 — Not Applicable.

1 · Current applicability status

Asɛm a aba — only what has come.

The Payment Card Industry Data Security Standard v4.0 (PCI DSS v4.0) applies to any organisation that stores, processes, or transmits cardholder data. As of 27 May 2026, EcoVent Africa Limited and its operating platform VPAY Genesis:

• Do not accept payment-card transactions. The current website surfaces are informational and waitlist-only. No "buy" button transacts. No checkout flow exists. No card data form is rendered anywhere on ecoventafrica.com or any subsidiary domain.
• Do not store cardholder data. No database in any layer of the stack — on-chain or off-chain — contains a primary account number (PAN), card verification value (CVV/CVV2), expiry date, or cardholder name in association with a PAN.
• Do not transmit cardholder data. No API endpoint accepts or relays card data. The institutional API surfaces (current mock and future production) handle attestation streams, token verification, and audit-trail data — never cardholder data.
• Do not contract third-party card processors. Stripe, Flutterwave, Paystack, or equivalent acquirers are not in the current vendor stack. There is no service agreement under which any party is processing cards on our behalf.

The auditor's 27 May 2026 report rated PCI DSS 2/5 with the note: "Limited payment processing evidence; no PCI compliance attestation found." The correct status is N/A by design; this statement converts the absence of an attestation into a documented exclusion, which is the standard PCI scoping outcome for a non-card business.

2 · Cardholder data environment (CDE)

Adwene di adanseɛ — the mind bears witness.

A Cardholder Data Environment, as defined by the PCI Security Standards Council, is "the people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data, as well as any connected-to or security-impacting systems." For EcoVent Africa Limited, the CDE is:

The empty set.

Because no system in the EcoVent Africa stack falls within the PCI definition of "stores, processes, or transmits cardholder data," no system is in scope for PCI DSS v4.0. Network segmentation, vulnerability scanning under Approved Scanning Vendor (ASV) regime, and Self-Assessment Questionnaire (SAQ) completion are accordingly not required at this time.

Adjacent regulatory frameworks (the Ghana Data Protection Act 2012, EU GDPR, AML/CFT under the Bank of Ghana's GANRAP framework) do govern the personal data the company collects (name, email, employer, role, country when submitted via diligence and waitlist forms). Those are addressed under Privacy Policy, Information Security Policy, and AML/CFT Summary.

3 · Documented exclusions

Sankɔfa — return and fetch.

The following surfaces are explicitly excluded from PCI scope, with the rationale stated:

• The Polygon Mainnet smart-contract stack. Ten production contracts at canonical addresses (see /compliance.html#contracts). On-chain transactions reference $SOV (an ERC-20 token) and reserve attestations — never card data. POL gas payments use the Polygon native token; no card is presented for any on-chain action.
• The Netlify-hosted website (ecoventafrica.com). Static HTML. Plausible Analytics for traffic metrics (privacy-first, no cookies). Netlify Forms for the waitlist and diligence-request flow — collects name, email, employer; never a card field.
• The institutional API surfaces (current mock + future production). Attestation streams, token verification, custody primitives, audit feeds. API authentication uses bearer tokens; no payment-card credentials are accepted as auth material.
• The GSU hardware fleet. Field devices for sealed XRF readings + GPS + cryptographic signatures. Hardware payload is metallurgical data; no card data exists at any point in the hardware lifecycle.
• The Ananse and Opɛ trading engines. Internal operational systems trading PAXG/USDT and BTC/ETH/SOL respectively on Binance and (with Futures) USDS-M. Auth via API keys held in macOS Keychain on operator workstations; never card data.

This list is exhaustive at the date of publication. Any future system addition that touches cardholder data will trigger an immediate scope re-assessment and is governed by the forward-state plan in §4.

4 · Forward-state plan

Nkrabea — the appointed time.

EcoVent Africa's medium-term product roadmap includes consumer-facing "Save in Gold" and "Borrow" functionality. When fiat-to-$SOV conversion is offered to retail users in jurisdictions where card-funded purchases are expected, PCI DSS v4.0 will become applicable. The forward-state plan below is committed in advance.

• Acquirer integration via a PCI Level 1 service provider. Card data will be tokenised at the acquirer (e.g. Stripe Connect, Flutterwave, or Paystack — selection criteria include Ghana operating licence + multi-jurisdictional Level 1 attestation). No PAN, CVV, or expiry will touch EcoVent Africa infrastructure; the acquirer's hosted fields handle entry directly to the acquirer's vault.
• Tokenisation reduces our scope to SAQ A. SAQ A is the lightest PCI assessment, applicable to merchants who fully outsource cardholder data handling. We commit to completing a SAQ A within 30 days of accepting our first card payment, and to maintaining it on the annual renewal cycle PCI requires.
• Network segmentation between payment and non-payment systems. The future payment service will run in isolated infrastructure with documented network boundaries to the existing attestation and trading systems. The on-chain layer remains intact and unaffected; the segmentation isolates the off-chain fiat surface.
• Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV). When card processing is live, we will engage a PCI-listed ASV (e.g. Qualys, Tenable, Rapid7) for quarterly scans of any internet-facing component connected to the payment service.
• Annual penetration test. The audit's Phase 1 Priority 2 recommendation (independent pentest) is already in commissioning and will explicitly cover any future payment surfaces from their first day live.
• Cardholder data flow diagram. Before any card payment is accepted, a documented data-flow diagram will be created showing every system the data touches, from card-entry through tokenisation through settlement. The diagram will be published (with operational details redacted) at this URL.

The privacy-first architecture and minimal off-chain footprint already established by VPAY Genesis substantially reduce the surface area that PCI compliance will need to cover. The auditor noted the same: "The privacy-first architecture provides a strong starting point for PCI compliance when the time comes."

5 · Self-assessment basis

Wofa di adanseɛ — the uncle bears witness, too.

This scope statement is a self-assessment by EcoVent Africa Limited as of 27 May 2026. It is intentionally transparent so that any reader — institutional investor, regulator, prospective partner, internal auditor — can independently verify the claim by inspecting:

• The public website source (no card form HTML).
• The smart-contract source on GitHub (ecovent-africa/vpay-sovereign · foundry-round2).
• The on-chain transaction history of the ten production contracts.
• The Netlify Forms configuration (waitlist + diligence; no card field).
• The vendor list in the Information Security Policy §5 (no PCI-acquirer is listed).

A formal third-party PCI scoping engagement is queued for Phase 3 of the 24-month institutional maturation programme (12–24 months), to be triggered ahead of any card-payment launch. The audit firm and the precise scoping methodology will be selected to align with the eventual SOC 2 Type II and ISO 27001 audit programmes for assessment efficiency.

Version 1.0 · Effective 27 May 2026 · Next scheduled review: 27 August 2026 or immediately upon any payment-system change, whichever sooner.

6 · Contact

Mate Masie — what I hear, I keep.

Compliance and scope questions: cco@ecoventafrica.com (Chief Compliance Officer)

Founder direct: Ano@ecoventafrica.com

Security disclosures: security@ecoventafrica.com

Version 1.0 · Effective 27 May 2026