Security Policy

1. Purpose, scope and how to read this document

1.1 This document is POSX's public statement of how we secure the POSX mobile application, the POSX websites, the systems behind them and the reward ledger we maintain for users. It is written for three audiences: users who want to know how their account is protected; partners, merchants and auditors performing due diligence; and security researchers who want to report something to us.

1.2 It covers the POSX consumer app, the POSX APIs and backend services, the POSX websites, the reward ledger, the wallet infrastructure and the corporate systems that hold user data. It does not cover the systems of partner merchants, payment networks, app stores or public blockchain networks, which are outside our control.

2. Security governance

2.1 Accountability for information security sits with our Chief Executive Officer and is exercised through a documented information security programme approved by the Board of Directors and reviewed at least annually and after any material change or incident.

2.2 The programme is written down. It comprises: an information security policy and supporting standards; an asset and data inventory; a risk assessment refreshed at least annually; documented roles and responsibilities; a training programme; a supplier assurance process; an incident response plan; and a set of measurable controls with named owners.

2.3 Risks are recorded in a risk register with an owner, a treatment decision and a review date. Risks that cannot be reduced to an acceptable level are accepted explicitly by the Chief Executive Officer, in writing, with an expiry date.

3. How we classify and protect data

3.1 Production data is not copied into development or test environments. Where realistic data is needed for testing, it is synthetic or irreversibly anonymised.

4. Encryption and key management

4.1 In transit. All connections to POSX services use TLS 1.2 or above with modern cipher suites; TLS 1.0 and 1.1 are disabled. HTTP Strict Transport Security is enforced on our web properties, and the mobile app pins the certificates of the endpoints it talks to.

4.2 At rest. Data at rest is encrypted using AES-256 or an equivalent approved algorithm. Restricted-class data is encrypted with keys separate from those used for other data, and sensitive fields are additionally encrypted at the application layer so that database access alone does not disclose them.

4.3 Keys. Cryptographic keys are generated and stored in our cloud provider's managed key management service, backed by FIPS 140-3 validated hardware security modules, never in source code, configuration files or environment variables checked into a repository. Keys are rotated at least annually and immediately on suspicion of compromise. Access to key material requires multi-party approval and is logged.

4.4 Secrets. Application secrets are held in a managed secrets store with short-lived, automatically rotated credentials. Repositories are continuously scanned for committed secrets, and any secret detected is revoked before remediation of the commit.

5. Reward ledger, user wallets and treasury

5.1 Reward balances are a ledger, not a chain. A user's reward balance is a record in POSX's own systems. It is not a blockchain token, and POSX does not hold user funds against it. The ledger is append-only, every entry carries the Proof of Spend record that produced it, and balances are reconciled against the underlying transaction records daily with breaks investigated and cleared within two business days.

5.2 User wallets are self-custodial. Where the app provides a wallet, it is provisioned through Privy. Key material is split so that a signature requires the user's authenticated device; POSX holds no key or key share that would let it move, freeze or recover a user's assets on its own. That is a deliberate design decision, and it is the basis on which POSX describes itself as non-custodial in its user-facing documents.

5.3 POSX treasury. POSX's own assets are held with Fireblocks under MPC key management. Movements require multiple approvers and pass a policy engine enforcing amount thresholds, destination allow-lists and velocity limits; no single individual can move treasury assets. Treasury assets are entirely separate from user wallets and are not held on behalf of users.

5.4 Smart contracts POSX deploys are reviewed by an independent security firm before deployment, and the reports are published at https://posx.io/security/audits. Contract upgradeability, admin key custody and timelock arrangements are documented at the same location.

6. Identity and access control

— Access is granted on the principle of least privilege, by role, on approval of the system owner, and is removed automatically when someone changes role or leaves.

— Multi-factor authentication is mandatory for all staff accounts and for every administrative interface.

— Access to production systems is time-bound and requested just-in-time, with the reason recorded; standing production access is not granted.

— Access rights are reviewed at least quarterly, and privileged rights monthly, by the system owner.

— Administrative sessions are logged, and sessions to sensitive systems are recorded.

— Corporate endpoints are managed, encrypted, patched and monitored; unmanaged devices cannot reach production or restricted data.

6.1 For users: accounts are protected by a password stored only as a salted, memory-hard hash, device-bound sessions, optional biometric unlock provided by the operating system, step-up verification for sensitive actions, rate limiting and lockout on repeated failures, and notification of new-device sign-ins and of changes to security settings.

7. Secure development

— Changes are made through version control, peer-reviewed by someone other than the author, and deployed through an automated pipeline; nobody deploys to production by hand.

— The pipeline runs static analysis, dependency and container scanning, secret scanning and infrastructure-as-code checks; a build fails on a finding above the agreed threshold.

— Dependencies are inventoried in a software bill of materials, monitored for known vulnerabilities, and patched under the timelines in section 10.

— Threat modelling is performed for new features that handle restricted data, move value, or change an authentication or authorisation boundary.

— Developers receive secure-development training at least annually, covering the current OWASP Top 10 and the OWASP Mobile Top 10.

8. Mobile application security

8.1 The app is built and tested against the OWASP Mobile Application Security Verification Standard (MASVS v2) and verified using the OWASP MAS Testing Guide at MAS Testing Profile L2. MASVS v2 replaced the old L1/L2/R verification levels with control groups (MASVS-STORAGE, -CRYPTO, -AUTH, -NETWORK, -PLATFORM, -CODE, -RESILIENCE, -PRIVACY); we hold evidence against each group.

— Authentication tokens and other secrets are stored in the platform keystore — the iOS Keychain or the Android Keystore — never in shared preferences, plain files or logs.

— Certificate pinning is applied to POSX endpoints, with a documented rotation and recovery plan so that a certificate change cannot brick the installed base.

— The app detects and responds to jailbroken, rooted, emulated, hooked or tampered runtimes, and restricts sensitive operations on them.

— Screenshots and screen recording are blocked on screens showing restricted data, and sensitive fields are excluded from system backups and from the app switcher preview.

— Debug logging, developer menus and test endpoints are compiled out of release builds.

— Deep links and inter-app communication are validated; no sensitive action is triggered by an unauthenticated deep link.

— The app ships a privacy manifest declaring collected data types, tracking domains and every required-reason API together with its approved reason, and every third-party SDK on Apple's published list carries its own signed manifest.

9. Infrastructure and network security

— Production runs in a major public cloud provider, named in the subprocessor list at posx.io/legal/subprocessors, in United States and Asia-Pacific regions on infrastructure defined as code, with no manual changes to running environments.

— Environments are segregated; production is isolated from development, test and corporate networks.

— Public endpoints sit behind a web application firewall with rate limiting, bot management and distributed-denial-of-service protection.

— Administrative interfaces are not exposed to the public internet and require an authenticated, device-attested path.

— Hosts and containers are hardened to a documented baseline and rebuilt from images rather than patched in place.

— Backups are encrypted, access-controlled, stored in a separate failure domain, and restore-tested at least every six months.

10. Monitoring, vulnerability management and testing

10.1 Security-relevant events from applications, infrastructure, identity and endpoints are centralised in a log platform with integrity protection and a retention period of 12 months, of which 90 days is immediately searchable. Alerts are triaged automatically, at any hour, to an on-call engineer, and reviewed by the security team each business day.

10.2 Vulnerabilities are triaged on severity using CVSS and remediated within the following targets, measured from the time POSX becomes aware:

10.3 An independent penetration test of the app, the APIs and the supporting infrastructure is commissioned at least annually and after any significant architectural change. Findings are tracked to closure and re-tested. A summary letter is available to partners under non-disclosure agreement from security@posx.io.

11. Suppliers and third parties

11.1 Before a supplier is given access to POSX data or systems it is assessed for security and privacy, proportionate to the sensitivity of the data and the criticality of the service. Suppliers handling restricted or confidential data must evidence an independent assurance report or an equivalent certification, and are re-assessed at least annually.

11.2 Every supplier processing personal information is bound by a written data processing agreement covering purpose limitation, confidentiality, security measures, sub-processing, breach notification to POSX without undue delay, audit rights, international transfer safeguards and deletion on termination.

11.3 Suppliers are inventoried with the data they process, their location and their assurance status. The list of those processing personal information is published in Appendix B of the Privacy Policy.

12. People

— Background screening is carried out before employment, to the extent permitted by local law, and at a level proportionate to the role's access.

— Everyone signs confidentiality obligations that survive the end of their engagement.

— Security awareness training is delivered at induction and at least annually, with phishing simulation and follow-up for those who need it.

— Access is revoked and devices recovered on the last working day as part of a documented offboarding checklist.

— Contractors and temporary staff are subject to the same controls as employees.

13. Incident response and breach notification

13.1 We maintain a written incident response plan naming the response lead, the escalation path and the communications owner. It is exercised at least annually through a tabletop or simulation, and reviewed after every exercise and every real incident.

13.2 Where a personal data breach occurs and the law requires notification, we notify: the relevant supervisory authority within 72 hours of becoming aware where the GDPR or UK GDPR applies; affected individuals without undue delay where there is a high risk to them; and any other regulator, partner or payment network within the period its rules or our contract requires. US state breach notification laws apply in parallel and are assessed for every affected state; where the Federal Trade Commission's Safeguards Rule applies, a notification obligation to the Commission arises for incidents affecting 500 or more consumers.

13.3 After every SEV-1 and SEV-2 incident we produce a written post-incident review covering timeline, root cause, impact, what worked, what did not, and corrective actions with owners and dates. Reviews are blameless and the actions are tracked to closure.

14. Resilience

14.1 Recovery objectives are a recovery time objective of 4 hours and a recovery point objective of 15 minutes for the services that hold reward balances and authenticate users. Business continuity and disaster recovery plans are tested at least annually and the results recorded.

14.2 Service status and incident communications are published at https://status.posx.io.

15. Independent assurance

15.1 We would rather publish an honest roadmap than an implied claim. This is where we are:

16. Coordinated vulnerability disclosure

16.1 Our commitment to researchers

16.1.1 We welcome reports of security vulnerabilities. If you act in good faith and follow this policy, POSX will not bring or support legal action against you in respect of your research, will not report you to law enforcement, and will treat your activity as authorised for the purposes of any computer misuse or anti-circumvention law we could otherwise invoke. This safe harbour is limited to POSX; it cannot bind a third party whose systems you touch.

16.2 How to report

16.2.1 Email security@posx.io with a description of the issue, the steps to reproduce it, its impact, and anything else we would need to confirm it. Encrypt sensitive detail with our PGP key, published at https://posx.io/.well-known/pgp-key.txt (fingerprint published alongside the key). We also publish a security.txt file at https://posx.io/.well-known/security.txt.

16.3 In scope

— The POSX mobile apps published by POSX US Inc..

— The POSX APIs and backend services.

— The POSX websites at posx.io and their subdomains.

— POSX smart contracts at the addresses published at https://posx.io/security/contracts.

16.4 Out of scope, and what you must not do

— Do not access, modify, delete or exfiltrate data belonging to anyone other than an account you own or have written permission to test. If you encounter user data, stop and tell us.

— Do not degrade the service: no denial-of-service, no load or stress testing, no spam, no brute-forcing of live accounts.

— Do not use social engineering, phishing or physical intrusion against POSX staff, users, merchants or offices.

— Do not test third-party services POSX uses; report those to their owners.

— Out of scope as findings: missing security headers or best-practice recommendations with no demonstrated impact, self-inflicted or theoretical issues, rate-limiting on non-sensitive endpoints without a working exploit, reports generated solely by an automated scanner, outdated software versions without a working proof of concept, and email configuration findings such as SPF, DKIM and DMARC unless you can demonstrate a practical spoofing attack.

— Do not publicly disclose the issue before we have shipped a fix and agreed timing with you.

16.5 Rewards

16.5.1 POSX does not currently operate a paid bug bounty and does not pay for vulnerability reports. We say that plainly rather than leaving it open, because an unclear position is the commonest source of dispute between companies and researchers.

16.5.2 What we do offer: we will credit you by name or handle on our acknowledgements page unless you ask us not to, we will tell you what we fixed and when, and we will co-ordinate public disclosure with you. If we introduce a paid programme we will announce it here, and it will not apply retrospectively to reports already made.

17. Reporting a security concern about your account

17.1 If you think your POSX account has been accessed without your permission, change your password immediately, sign out of other devices in Settings → Security, and contact support@posx.io. If you have lost the device that holds your account, tell us and we will suspend access pending re-verification.

17.2 POSX will never ask you for your password, a one-time code, or a recovery phrase — not by email, phone, SMS, chat or social media. Anyone who does is attempting fraud. Report it to security@posx.io.

Appendix A — Control mapping for due diligence

This mapping helps a partner, auditor or reviewer trace a control in this document to the framework requirement it satisfies. It is a navigation aid, not a certification.