Technology

For technology teams and traders

CTOs, platform engineers, and the traders on the desk.

DojiPad runs single tenant: one private copy, used by your firm alone. On this page, "the tenant" means that private environment. It runs in your firm's own Microsoft Azure subscription, which is your firm's account on Microsoft's cloud. Staff sign in through your firm's identity provider, Microsoft Entra ID, the directory that already manages their logins. The encryption keys are your firm's. Egress means data sent out of your environment. DojiPad runs fully locked down on every deployment (set out below): outbound traffic is denied by default in every subnet, with exceptions only for the Microsoft services it runs on. The software makes no calls to ARQNXS: no telemetry (usage data sent back to a vendor) and no vendor endpoint (a vendor server your data could reach). The vendor cannot see your firm's trades. Nothing in DojiPad sends your data to us, and your firm holds every key and password from day one: your administrator runs the setup, and we guide.

0DATA SENT TO ARQNXS · NO TELEMETRY

2SEPARATE SIDES (PLANES) · OFFICER AND TRADER

94BASIS POINTS A YEAR · THE DOCUMENTED COST OF UNMANAGED BIAS¹

30DAY PILOT · ONE DESK · IN YOUR TENANT

RUNS ON Microsoft Azure · Entra ID

¹ Essentia Analytics client research, 2020. Full sourcing in Exhibit A.

1 What you provide What DojiPad needs from your firm, and what it doesn't touch. →
2 Architecture What runs inside your environment, and the evidence the deployment produces. →
3 Security brief The deployment boundary in your Azure tenant, and what each part can send out. The evidence it produces, identity and roles, and record keeping. →
4 Identity, roles and keys Your Entra ID groups decide what each person can open. →
5 Integration Where it runs, what leaves your tenant, and which AI model it uses. →
6 Onboarding Who provides what, and when. →
7 After go-live What your firm runs, and what ARQNXS does. →
→ How it works The decision timeline, the two separate sides, and a session run live. →
→ The trader's side What crosses to the firm, and what the firm never sees. →
→ Breach prediction A forecast made at each committed plan, scored against what the trader does next. →
→ Papers Four short papers on the thinking behind the system, and the form to subscribe. →
→ The walkthrough Fifteen minutes on the live product, using a simulated firm. →
→ Request a briefing DojiPad running live on a simulated firm. We show it first from the list of limit breaches, then from the trader's side. →

What DojiPad needs from you, and what it doesn't touch

DojiPad needs:

an Azure subscription with a new resource group (a folder for DojiPad's Azure resources);
Microsoft Entra ID for sign-in, with six security groups mapped to roles;
an Azure OpenAI resource (Microsoft's hosted AI model service) in your subscription, with a chat model deployment (the AI model DojiPad talks to);
a DNS name on your domain, and a certificate for it from your certificate authority or Azure Key Vault;
a named officer from risk or compliance, for the two limit workshops;
your limit documents and capital figures (NAV, the net asset value, firm book or desk book).

It doesn't touch:

your order and execution systems;
your market data;
your traders' computers.

Nothing to install: traders, risk and compliance use DojiPad in the browser.

Architecture and security

How data moves through the system

One diagram shows the whole design. DojiPad runs in your firm's own cloud account. Its server software connects only to your firm's own database, vector store (the search index the AI coach reads from), model endpoint (where the AI model runs) and directory. Market data and the execution feed (executed trades sent back from your order system) are incoming connections on the roadmap. The coaching conversation passes between the trader and DJ, DojiPad's AI coach. It never leaves the trader plane, the trader's private side of the system. A committed plan is one the trader has confirmed as the plan of record. Committed plans cross one boundary, to the officer register (the officers' list of limit breaches). Orders go through your firm's own execution path, which runs entirely around this system. Nothing in the deployment sends data to ARQNXS. It runs fully locked down, as set out under Full lockdown, on every deployment, below.

The architecture diagram

Never leaves the trader plane Firm records, inside your tenant Incoming connections (roadmap) Feed of executed trades (roadmap) No data sent to ARQNXS

01 / 06MARKET DATA WILL ARRIVE OVER ITS OWN CONNECTION (ROADMAP), ONE WAY, INTO DOJIPAD.

THE DIAGRAM AS TEXT

Market data will arrive over its own connection. That connection is on the roadmap: no market data feed is connected today. It will be a one-way connection into DojiPad.
The coaching conversation passes between the trader and DJ on the trader plane. It is private. It is never summarized, scored or forwarded.
When a trader commits a plan, the plan crosses one boundary, from the trader plane to the firm plane. There it is checked against your firm's limits (the mandate).
Risk and compliance read limit breaches (observations) and records on the firm plane.
Orders run through your firm's own order management system (OMS) and execution management system (EMS), entirely around DojiPad. The system cannot route or block orders.
An execution feed from the OMS back into the system is on the roadmap. It is not connected.
Egress (data sent out): denied by default in every subnet; the application subnet reaches only the Microsoft services DojiPad uses. Nothing in the deployment sends data to ARQNXS.

SINGLE TENANT

The whole system is installed inside your firm's own cloud subscription. It uses your firm's identity provider and your firm's keys. The software makes no calls to ARQNXS and sends no telemetry. There is no vendor system it sends your firm's data to. The vendor cannot see your firm's trades. Nothing in DojiPad sends your data to us, and your firm holds every key and password from day one: your administrator runs the setup, and we guide.

TWO PLANES

The system has two separate sides, called planes. The firm plane holds the limit findings from the checks against your firm's limits (mandate evaluations), the limit breaches (observations) and the audit trails (evidence chains). It is built for risk and compliance officers. The trader plane holds the coaching conversation itself. It is separated by design: nothing from it is summarized, scored or flagged across to the firm. Coaching works only when traders speak candidly. That needs a boundary no setting can remove.

FORECAST ENGINE

The forecast engine predicts limit breaches. A prediction is made at each committed plan. It is scored against what the trader does next. The scores are on the board, per trader, as forecast against what actually happened. Scoring against fills (the trades as executed) is called the execution horizon. It arrives with the execution feed.

DEPLOYMENT: Single tenant, in your firm's cloud subscription · Microsoft Azure, your firm's region, your firm's keys
IDENTITY: Microsoft Entra ID · your firm's directory; officer screens and trader screens are separated by role
DATA EGRESS: Denied by default in every subnet · the application subnet only to the Microsoft services DojiPad uses; no telemetry, no vendor endpoint
EXECUTION PATH: Not in it · the system cannot route or block orders
RECORDS: Audit trail (evidence chain) · plans and limit checks (evaluations), limit breaches (observations), daily sign-offs (attestations); the audit log and the acknowledgement record (ledger) are append-only
GOVERNANCE: Regulatory alignment memo · available on request before a briefing; architecture review with your firm's security team, under NDA

II.

One trading session, step by step

YOUR FIRM'S AZURE TENANTPRIVATE NETWORK · FIRM KEYS · ENTRA ID

THE TRADER'S SIDETHE COACHING CONVERSATION

COACH

This is your third session this week with a re-entry planned within 15 minutes of a losing trade. Your own record shows how often those lose.

STAYS ON THE TRADER'S SIDE

TRADER

Fair point. I'll trade smaller and wait for my price level this time.

STAYS ON THE TRADER'S SIDE

TRADER

Committing the plan: long AAPL, with my reasoning attached.

PLAN → FIRM'S SIDE

COACH

As it stands, this plan puts 20% in a single stock. Your firm's limit is 15%. Better to resize now, while it is still a plan.

STAYS ON THE TRADER'S SIDE

TRADER

Resizing to 12% and committing again.

PLAN → FIRM'S SIDE

THE FIRM'S SIDELIST OF LIMIT BREACHES · RISK & COMPLIANCE

10:02:41Plan committed · long AAPLCOMMITTED

10:02:42Single-name concentration limit breachProjected exposure 20.0% of NAV against a 15.0% limitPlan: long AAPLOVER THE LIMIT

10:03:15Plan changed · checked again at 12.0%WITHIN LIMITS

10:03:15Saved to the audit trail · plan, check, breach, changeRECORDED

EVERYTHING ABOVE RUNS INSIDE THIS BOUNDARY. THE AI MODELS, THE DATA, THE RECORDS: ALL OF IT.

The conversation on the left is never summarized, scored or passed on. Committed plans, and any limit breaches found with them, cross to the officers' list of limit breaches. Nothing else does. It runs fully locked down: nothing in it can send data out except to the Microsoft services it runs on.

Why Azure, and what if you don't use it

DojiPad's AI model runs as an Azure OpenAI resource in your own subscription, so plans and conversations go to your model, not ours. That is why DojiPad needs Azure.
Your security team should review that resource's data-handling settings with Microsoft, such as abuse monitoring.
If your firm uses Microsoft 365, you already have Entra ID, the sign-in service DojiPad uses.
If you run on another cloud or on your own servers, your firm can open an Azure subscription just for DojiPad. It stays in your firm's name, on your bill and under your sign-in controls, and it connects to nothing else you run.
Other clouds aren't supported today.
Running cost: about $200 a month for one environment, plus Azure OpenAI usage, which depends on how much the desk uses DJ. You pay it to Microsoft.

II.

What runs inside your tenant

Inside your firm's tenant are the following. The application. The model endpoint: an Azure OpenAI resource (Microsoft's hosted AI model service) in your firm's own subscription. The deployment points to it; the vendor never creates or holds it. The data VM (virtual machine: a server in your cloud account). It keeps your firm's records on its own persistent disk, which survives any redeploy. The HTTPS gateway your users connect to, on your own domain: the only way in. And your firm's Entra directory, for identity. The evidence sink is in the tenant too: the flow-log storage and the log workspace, where network and system logs are kept.

Full lockdown, on every deployment

The application, the database server and the web client run inside your virtual network, on private addresses.
The only way in is the HTTPS gateway, on your own domain, with your own certificate from your certificate authority or Azure Key Vault.
Outbound traffic is denied by default in every subnet. The application subnet's only exceptions are traffic inside the virtual network and the Azure service tags for Microsoft Entra ID, Azure OpenAI and Azure Container Registry, used with your own resources. The gateway can reach only the application, and the database server nothing outside the virtual network.
All software, including the database server's updates, comes from your own container registry, so no part of the deployment ever needs outbound internet access.
No password or key is stored on any server's disk.

A service tag covers that Microsoft service as a whole; DojiPad is configured to use your own resources within them. The application uses them to reach your own model endpoint, and Entra to verify sign-in tokens. In sealed mode this rule is always on, and no configuration setting can weaken it. Nothing in the deployment sends data to ARQNXS.

Security boundaries

The trader's side and the firm's side are separated in the API (the interface the screens call), not just on screen. No firm-side route (an address in the API) returns trader-side data, and officer routes answer a trader with "not found".
DojiPad stores no user passwords; sign-in runs through your Entra ID.

DojiPad Institutional · Security brief

The boundary, the evidence, the roles, the records

PREPARED FOR REVIEW UNDER NDA · CONTACT NIGEL@ARQNXS.COM

Deployment timeline

Setup takes one to two weeks after your firm's approvals: deployment into your firm's Azure account and two limit workshops. It is not part of the 30 days. Before setup, your firm provides what DojiPad needs, as listed under what DojiPad needs from you.

ApprovalsYour timeline
SetupOne to two weeks
Go-liveThe pilot clock starts
30-day pilotCounted from go-live
DecisionAgainst the criteria agreed at kickoff

Setup is not part of the 30 days.

Step	Who	Time
1. Approvals	Your firm	Your usual vendor and security review
2. Sign-in setup in Entra ID	Your Entra administrator	About 30 minutes, with our installation guide
3. Deployment	Your Azure administrator, with your own accounts, keys and passwords; we guide on a call
4. Two limit workshops	Your risk or compliance owner, with us	Two sessions
Steps 2 to 4 together		One to two weeks after your firm's approvals
5. Go-live	Users sign in with Entra ID	The pilot clock starts
6. Pilot	The desk	30 days from go-live

III.

Evidence the deployment produces

This page shows no certification badges. Instead, the deployment's own tools produce three artifacts.

EGRESS MANIFEST: A list of every kind of network connection the server can open, per deployment mode, with hosts, purpose and protocol. It is generated from the same registry the running system enforces. So the document cannot drift from the policy. If the manifest is out of date, the build gate (the automated check before release) fails. It covers DojiPad's server software. The network rules, the gateway, the web client, the database containers and the servers' operating systems are outside it.
FLOW-LOG VERIFICATION: Flow logs are Azure's record of the network connections in your tenant. We use your tenant's own flow logs. Each flow is checked against the manifest and sorted: allowed and expected, allowed but unexpected, denied, or infrastructure. Each run includes a deliberate test connection that must be refused (a denied-egress probe). The run fails unless that probe shows up as denied. An empty log would not prove the rules work. It covers the machines that appear in the logs: in our reference rehearsal, a test server in a subnet under the same rules as the application subnet. It shows that the network rules refuse traffic, not what the application itself sends.
PLANE-DENIAL REPORT: A table of roles against screens, written for a compliance reviewer. It shows which roles can open each oversight screen. It shows what a refused user receives: a 404 (the "not found" response), never a 403 (the "forbidden" response). It also lists the built-in guarantees that firm-plane routes cannot read trader-plane records. Every row is rechecked live, against real routes and a real database, on every gate run. It runs in our checks before every release, against a test database, not against your deployment.

We review these live with your firm's security team, under NDA.

At go-live, the deployment is checked by hand for:

health: the application is up and answering;
unauthenticated calls refused: a request without a valid sign-in gets nothing;
trader sign-ins refused on officer routes: a trader who calls a firm-side address gets "not found".

In our reference rehearsal, an evidence VM (a test server) behind the same network policy logged 919 denied flows, and no unexpected traffic was allowed.

VI.

What a security review under NDA covers

The network layout of the private deployment, shown live in your firm's cloud account.
What each part of the deployment can send out, and the evidence for each part.
The separation between the trader's side and the firm's side, shown from an officer's seat and a trader's seat.
Identity: how your Entra ID groups (your firm's staff directory) map to roles, and what each role can open.
The records: where the audit trail is kept, and how it is exported.

The two-page security brief covers the boundary, the evidence, identity, and how long records are kept (retention): read it as a page or download the PDF.

Request a briefing

IV.

Identity, roles and keys

Sign-in runs through your Entra tenant, your firm's own Entra ID directory. It uses two app registrations (the entries in Entra that let DojiPad's API and its web client use your sign-in) and six security groups. Memberships link when each person first signs in.

Your Entra ID groups map to these roles: trader, desk manager, risk, compliance, auditor and strategy. Each officer screen opens only for roles with that capability. The system enforces this; it is not left to convention. Running the organization's settings is not oversight: an administrator's rights do not include reading the officer register.

DojiPad uses three secrets: your Azure OpenAI key, the database password and an encryption key. You generate them, keep them in your secrets manager and enter them at deployment.

Where your records are kept

Records live in your firm's own storage, under your firm's retention policy. Every oversight screen prints an audit-stamped PDF on demand. Opening any page that can be exported is logged as an audit event. The stamp shows the as-of time, the officer who generated it and the scope. It also has the monitoring line, which names any limits (clauses) that are not monitored.

Plans, limit findings (the checks that found a breach or a warning), acknowledgements, daily sign-offs and audit events are stored in your database, in your subscription. The audit log and acknowledgements are append-only: DojiPad can add to them but can't change them. Plans and their limit checks can still be edited, and anyone with the database password can change any record, so database access belongs under your firm's controls. NAV figures and execution records are append-only in DojiPad too. How long you keep them is your firm's policy. Access is by role, from your Entra groups. Trader-side records aren't encrypted at the application layer, so your database administrators can read them. Access to the database itself is governed by your firm's controls, as for any system you host.

Questions technology teams ask

Where does it run?

Inside your firm's own Azure subscription. Azure is Microsoft's cloud, and a subscription is your firm's own account in it. It is single tenant: the copy serves your firm alone, and nothing is shared with other customers. Four parts run there. The application. The data VM, a virtual machine that holds the records on its own persistent disk (storage that survives a restart). The gateway, the single entry point for users. And your firm's Entra directory, Microsoft's service for user accounts and sign-in. Nothing is hosted by the vendor.

Where does our data go?

It stays in your firm's own Azure account, where DojiPad runs fully locked down. Its AI model is your own Azure OpenAI resource; your security team should review that resource's data-handling settings with Microsoft. Outbound traffic (egress) is denied by default in every subnet. The application subnet's only exceptions are traffic inside the virtual network and the Azure service tags for Microsoft Entra ID, Azure OpenAI and Azure Container Registry, used with your own resources. The gateway can reach only the application, and the database server nothing outside the virtual network. Nothing in the deployment sends data to ARQNXS. The egress manifest lists where DojiPad's server software may connect, and the flow-log check shows that the network rules refuse other traffic.

Which AI model does it use, and where?

An Azure OpenAI resource serves the model. Azure OpenAI is Microsoft's service for running OpenAI models, and the resource sits in your firm's own subscription. The DojiPad deployment points to that resource. It never creates it or holds it. Which model deployment it points to is a configuration setting your firm can read.

How do roles work?

Groups in Entra ID map to six roles: trader, desk manager, risk, compliance, auditor, and strategy. Entra ID is Microsoft's directory of your users and their groups. Officer screens are gated by capability: only a role with the right permission can open them. Someone without that permission gets a 404 ("page not found"), never a 403 ("access denied"). So they cannot tell that the screen exists. Administration is not oversight: an administrator does not get access to the officer screens.

Who holds the records, and for how long?

Your firm holds them, in its own storage, under its own retention policy (its rules for how long records are kept). Every oversight screen prints a PDF on demand, with an audit stamp on it.

Who does what during deployment

Your firm	ARQNXS
Azure subscription and resource group	Deployment template and installation guide
Azure OpenAI resource and model deployment	Guidance on a call while your administrator deploys
Running the whole setup, with your own accounts, keys and passwords	Each version of DojiPad, published for you to import into your own registry
A DNS name on your domain, and a certificate for it from your certificate authority or Azure Key Vault	We never hold your keys, passwords or access
Entra app registrations, groups and users	The three evidence documents (see the evidence the deployment produces)
Secrets in your secrets manager	Two limit workshops
Approvals and security review	Updates and support
	A security review under NDA

II.

Pilot cost, who provides what, and when

PRICE AND CREDIT: $10,000· credited in full against the first year when you subscribe. After that, the subscription is annual. In year one you have a 90-day right to terminate.
IN ONE LINE: $10,000 · 30 days from go-live · one desk, up to six traders, unlimited oversight seats · credited in full against year one if you continue
SEATS: Up to 6 trader seats· oversight seats unlimited, as always.
THE FIRM PROVIDES: a Microsoft cloud account (Azure), with an Azure OpenAI resource: the Microsoft AI service DojiPad uses;
an administrator for the deployment;
the user groups for your staff logins;
the document that sets out your firm's limits;
a named officer: your risk or compliance owner, for two workshops;
the desk's traders, from go-live.
ARQNXS PROVIDES: Guidance on a call while your administrator installs DojiPad, two workshops to set up your firm's limits, and the kickoff decision meeting, in that order.
ORDER: First, your administrator installs DojiPad in your firm's cloud account, with our guidance, and we set it up with your firm's actual limits in two workshops. This setup comes before the pilot and is not counted. At go-live, the kickoff decision meeting takes place. The thirty days run from that day.
EXIT CRITERIA: Agreed with each firm before the pilot begins. Examples: officers use the list of limit breaches in their daily review; how quickly breaches are acknowledged; how many traders who opted in stay in for the thirty days.

Request a briefing See the price list

After go-live: who runs what

Your firm	ARQNXS
Azure running costs: about $200 a month for one environment, plus Azure OpenAI usage, which depends on how much the desk uses DJ. You pay it to Microsoft.	We publish each new version with upgrade steps and release notes; your administrator installs it (as new container images, packaged versions of the application, in your own Azure Container Registry)
VM and OS (operating system) patching; backups of the data disk	Guidance when the model version changes
Monitoring and alerts in Azure Monitor, Azure's monitoring service	Support, direct from the founder (below)
Model deployment, quota (how much model capacity you have) and version changes	No access to your environment needed
User access in Entra ID; installing each new version	We never hold your keys, passwords or access

We never need access to your environment. Your administrator reads the logs, with our guidance.

Support comes directly from the founder, at any hour, with a response within one hour.

What DojiPad doesn't do yet

Today DojiPad checks plans, not executed trades. It doesn't yet read market data or your executed trades (the execution feed). Both are on the roadmap, as one-way connections into DojiPad.

What that means today:

DojiPad sees the plans traders state. Your desk decides which decisions need a stated plan, for example every new position or anything above a set size. Until the execution feed is connected, your team checks coverage against its own order log.
Limits are checked on the plan as stated, using the plan's own price and your capital figures (NAV, firm book or desk book, as each limit specifies).
Comparing what was planned with what was executed starts when the execution feed is connected.
Each breach prediction is checked against the trader's next committed plan. Checking predictions against executed trades arrives with the feed.
The product says so on screen: “Session monitoring is not active — no execution feed is connected. Silence here is not a clean bill.”