Regulatory perimeter, security posture, examination evidence.
What is in scope, what is out of scope, and what we publish. For procurement, security, and compliance teams reviewing XVICA as a vendor.
What XVICA is, and is not.
XVICA LTD is a software vendor and operator. It is not authorised or regulated by the Financial Conduct Authority or any other financial regulatory body. The perimeter below is definitive: it sets the scope of every engagement, every venture, and every contract.
XVICA does not
- iHold client money or customer funds.
- iiSafeguard funds under the Payment Services Regulations.
- iiiInitiate payments on its own behalf.
- ivProvide investment advice, asset management, or financial planning.
- vAct as a regulated intermediary in any FCA-defined activity.
XVICA does
- iBuild, operate, and license software for regulated institutions.
- iiSpecify systems against the regimes that examine them — DORA, SOC 2, PCI-DSS, FIPS 140-2, ISO 20022, BCBS 239.
- iiiProduce examination evidence, control mappings, and assurance artefacts as deliverables.
- ivOperate its own ventures (Techvica) under the same engineering and assurance standards.
Company record
XVICA LTD is a private limited company registered in England and Wales (Companies House No. 16 270 449). Statutory filings are on the public register. The full legal disclaimer governing this site is published at /legal/disclaimer.
Zero-trust by default. Evidence by design.
Every service-to-service call is mutually authenticated. Every human request runs through an identity-aware proxy. Every privileged operation is brokered with short-lived credentials. Workload identity is distinct from human identity.
Cryptographic operations on regulated data use FIPS 140-2 validated modules (typically Level 2 or Level 3 HSMs). Key rotation, quorum recovery, and segregation of duties are enforced operationally.
Security infrastructure capability- i
Identity
Workload and human identity separated. Per-request policy enforced by identity-aware proxies and mutual TLS.
- ii
Encryption
FIPS 140-2 validated modules for regulated data. Encryption at rest and in transit, treated as baseline rather than retrofit.
- iii
Audit
Audit-grade evidence is a property of the platform, not a downstream report. Every privileged action is recorded with the identity that made it.
- iv
Resilience
DORA-aligned operational resilience: ICT risk management, incident reporting, and threat-led testing are designed in, not bolted on.
What we map to, and how to read it.
Regulatory obligations are structured inputs to specification. FCA Handbook sourcebooks, PRA rulebook sections, DORA, MiFID II, EMIR, Basel III/IV, PCI-DSS, and GDPR obligations are mapped to controls; controls are mapped to tests. Examination packs are produced from live system evidence.
Standards mapping
Direct map from standards (SOC 2, PCI-DSS, FIPS 140-2, DORA, ISO 20022, BCBS 239) to the platform surfaces that implement them.
The discipline of immutable evidence
How XVICA treats audit-grade evidence as an architectural property, and why immutability is the cheapest insurance regulated infrastructure can buy.
Idempotency and exactly-once settlement
The patterns that keep settlement systems correct under partial failure, and the audit trail you need to prove what happened in any one of them.
Glossary
Terms used across regulated infrastructure — settlement primitives, regulatory frameworks, security concepts — defined in operating rather than marketing language.
04 — Diligence
Bring the questionnaire. We answer in specifics.
Vendor due diligence, security review, or regulator-driven questions: send the document. We respond with mapped evidence against your control framework, not a generic capability deck.