Arxxora — infrastructure for tokenized markets

Issuing a private market instrument should not take a blockchain team.

Arxxora is the issuance, compliance and servicing layer for private market instruments in Europe, delivered as an API, with the rules of each offering enforced by the contract at the moment a position moves.

Project dossier · October 2026 · Lisbon

Entity
Arxxora, Lda. being established in Portugal
Economic activity
CAE 62100 Atividades de programação informática, with 63100 as secondary
Market
European private markets funds, private credit, securitisation
Stage
Platform built and tested pre-audit, operations targeted for 2027

Part 1

Who this is for Issuers and servicers of instruments that are already regulated, not retail crypto products.

The market, and who moves inside it

Private markets in Europe run on instruments that are deliberately illiquid, closely held and heavily documented. The paperwork around one offering is substantial, and almost all of it is handled by hand.

  • Fund managers and AIFs

    Closed-ended vehicles in Luxembourg, Ireland and Portugal, where the register of participants, the capital calls and the distributions are administered manually or by a third party at a per-event cost.

  • Private credit and securitisation

    Issuers of notes and participations where the coupon, the withholding and the amortisation schedule have to be right every period, for holders in several jurisdictions at once.

  • Placement and servicing agents

    The transfer agents, depositaries and law firms around the offering, who carry the operational burden and whose work is the thing being automated, not replaced.

Part 2

The pattern Each of these is survivable alone. Together they are why one issuance takes two quarters.

What goes wrong today, and what replaces it

None of these problems is exotic. They are the ordinary operating reality of a firm issuing something that is not listed, and they are expensive in staff time rather than in software licences.

The painWhat Arxxora puts in its place
Tokenizing an offering means hiring a blockchain team, or six to twelve months with an integrator, per issuance. An API call creates the instrument with its rules already configured. The infrastructure is written once and reused across offerings.
The register lives in a spreadsheet, and whether it matches reality is discovered when someone asks. An indexer reconciles positions against supply on chain at a fixed block. A divergence is an event the operator is told about.
Compliance is a clause in a document and a promise from an operations team, checked after the transfer has happened. The rule is applied by the contract. A transfer that breaks it does not settle, and the refusal names the rule in words support can read to the investor.
A coupon with withholding by tax residence, across a few jurisdictions, is a spreadsheet and a long evening. Entitlement is fixed at a record date, withholding follows each holder's residence, and the tax is delivered separately to the treasury.
The sale dies in a third-party risk questionnaire about resilience, subprocessors and exit. Those answers are endpoints, not a PDF someone has to assemble: a resilience posture, a subprocessor register and a full export, available at any time.

Part 3

Note These are engineering requirements inside the product. They are not legal advice, and each client's counsel decides what applies to their offering.

Built to the regulation, not around it

Almost everything our clients tokenize is a financial instrument. That places it outside MiCA and inside the securities regime, which changes what the software is allowed to do and what it has to be able to prove.

  • MiFID II Client categories are a field in the identity registry and a rule the contract enforces, so an instrument restricted to professional investors cannot reach a retail wallet.
  • Prospectus Regulation The exemptions that depend on a holder count or a minimum ticket are enforced as caps, rather than monitored and reported after the threshold is crossed.
  • AIFMD Transfer restrictions, lock-up periods and eligibility conditions are configured per offering and applied without an operations team in the path.
  • GDPR, Article 17 No personal data is written on chain. The registry holds the hash of the KYC dossier, the country, the category and the validity, which is what makes erasure enforceable against an immutable structure.
  • DORA Resilience posture, the subprocessor register and a full data export are routes in the API, because a client in scope has to evidence them about their providers.
  • AML and sanctions Screening with a review queue and periodic rescreening, with a wallet blocked from the allowlist while an alert is open.

Arxxora is a software vendor, not a financial intermediary. There is no order book and no delivery versus payment in this software, and it never holds client money.

Both were designed out rather than left out. Raising, marketing, the investor relationship, the cash account and the choice of rule stay with the client or an authorised third party. A feature request that crosses that line is a decision about what company this is, not a sprint.

Part 4

Seat Portugal, inside the EU single market, which is where the clients and the regime both sit.

The company and the expertise behind it

Arxxora is being established as a Portuguese Lda. Its registered activity is software development, CAE 62100, with computing infrastructure and data processing, CAE 63100, as a secondary activity. It is deliberately not registered under any financial services activity, which matches the boundary described in Part 3.

The expertise behind it sits where this work actually lives: European securities regulation, compliance engineering, and the distributed systems these instruments settle on. The regulatory layer is not a developer's reading of a summary. It is modelled by practising legal expertise in these exact instruments, with the citations carried in the code rather than in a separate memo.

Arxxora is specialist by design rather than by scale. The team grows through 2027 against the plan in Part 5, and only where a discipline is genuinely needed.

Part 5

Dependency The audit sets the pace. Recognised firms queue four to eight weeks, and that clock starts when the slot is booked, not when the code is ready.

The plan to begin operating in 2027

The platform is built and tested. What remains before a client's instrument can settle on it is assurance and production hardening, in this order.

  • Q4 2026

    Public network and the audit slot

    Deploy to a public test network, where latency, node failures and chain reorganisations are real rather than simulated. Book the external audit in parallel, so the queue becomes working time.

  • Q1 2027

    External audit and key management

    Two audit rounds with nothing high or critical left open. Signing keys move into a key management service with rotation and recovery both tested, not merely designed.

  • Q2 2027

    Production integrations

    A real KYC provider and a live sanctions feed replace their development stand-ins. A restore is performed rather than assumed, because a backup that has never been restored is not a backup.

  • H2 2027

    First issuance with a client

    A pilot offering taken end to end with a real issuer: instrument created, investors allowlisted, subscriptions allotted, a coupon paid with withholding, and the register reconciled against the chain.

Part 6

Why this is here Anyone who evaluates infrastructure will ask. Better that they read it from us.

Where it genuinely stands

The platform runs its full issuance lifecycle end to end, across two networks at once, under 206 automated tests. It has not been audited externally, and it has never been deployed with real value.

There is a product that works and has never touched anyone's money. The distance between those two states is an audit and three integrations, which is what Part 5 describes. Nothing on this page should be read as a claim that it has been crossed.