# Kronos X Member Portal, User Guide

**Document status:** revision 1.7, 20 October 2026 (revision 1.6: 11 September 2026, revision 1.5: 10 September 2026, revision 1.4: 10 September 2026, revision 1.3: 19 August 2026, revision 1.2: 17 August 2026, revision 1.1: 17 August 2026, revision 1.0: 12 August 2026). Covers the member web portal
of Kronos X v2.0 "Pacifica". This guide is for a member firm's operations staff
using the portal in a browser. Engineers connecting member systems use the
separate Member API reference; nothing in this guide is required for API
integration.

The portal is a live view of your membership: balances, positions, orders,
quotes, statements, regulatory figures and messages from the venue, read from
the same engine your API integration talks to. The header always shows the
member code you are signed in as and the venue sequence number the figures are
current to; most pages refresh themselves every few seconds. Since revision 1.7
the header also names the portal's build: Kronos X followed by the release
version (for example Kronos X 0.20261019.1234), or development build on an
installation that does not run a release. Quote it when you report a problem
seen in the portal.

## 1. Signing in

- Portal credentials (member code and password) are issued by venue operations
  during onboarding. The portal address for each environment is in your
  onboarding pack.
- Sessions end after 12 hours or a venue restart; simply sign in again. Use the
  Sign out button when leaving a shared machine.
- Change your password on the **API and limits** tab: minimum 12 characters,
  effective from your next sign in, sessions already signed in stay valid.
- Lost password: venue operations issue a reset. If you suspect your password
  or a signed-in session is compromised, contact venue operations immediately;
  they can cut every live session and issue a fresh login at once.

### 1.1 Two-factor sign-in (19 August 2026)

- After the member code and password, the portal asks for a six-digit code from
  an authenticator app (Google Authenticator, Microsoft Authenticator, Authy,
  1Password or any app that supports time-based one-time codes; codes change
  every 30 seconds).
- Your FIRST sign-in after this feature is switched on shows a QR code and a text
  key: scan the QR with the app (or type the key), then enter the code the app
  shows. That enrols the authenticator for your portal login and signs you in.
  Every later sign-in asks for the current code only. Keep the authenticator with
  the people who use the portal login; the code screen shows the account label
  `Portal:<your member code>` and the issuer Kronos X.
- Five wrong codes end the sign-in attempt (start again from the password); ten
  wrong codes inside fifteen minutes lock the second step for fifteen minutes.
  The sign-in page also limits attempts per network address.
- Lost or replaced phone: contact venue operations, who verify the request with a
  known contact and reset the enrolment. That ends every signed-in portal session
  of your member at once, and your next sign-in shows the QR code again.
- The venue never asks for a code by phone or e-mail and never shows the key
  again after enrolment; if you cannot enrol, contact venue operations rather
  than sharing a screenshot of the sign-in page.

## 2. Overview

One card per settlement currency account: equity, balance, available funds,
initial margin (position and order margin separately), maintenance margin,
unrealised PnL and the equity to maintenance margin ratio. Below it: your risk
status (NORMAL, MARGIN_CALL or worse), your member status and role, your net
positions per instrument (quantity, average entry, mark, unrealised and
realised PnL, accrued funding, and the ADL rank, where more filled squares mean
closer to the front of the auto-deleverage queue), and 30 day activity totals
(trades, notional, fees, maker share). Asset holdings outside the settlement
currency (revision 1.5) are listed under the cards, one line per asset with
the total, reserved and free amounts; a EUR balance also shows an
informational, non-binding USD equivalent at the ECB euro reference rate of
the stated date, or no figure at all when the venue holds no rate from the
last five days.

The red **Cancel ALL working orders** button (also on the Orders tab) is the
kill switch: after confirmation it cancels every working and conditional order
across all instruments. Positions are unaffected, and open RFQ requests and
quotes are not withdrawn; manage those on the RFQ tab.

## 3. Markets

Pick an instrument to see its ticker line (last, best bid, best ask, mark,
funding rate where applicable), the order book to 15 levels with depth bars,
the mid and spread, recent venue trades, and your own conditional orders on
that market. The page refreshes every few seconds while open. The Markets tab
places no orders. Book order entry runs over your API or FIX integration,
except SECURITY markets, which the DLT Market tab (section 10a) trades from the
browser; requests for quotes, quotes and acceptances are on the RFQ tab.

## 4. RFQ

RFQ markets have no order book: you request quotes, other members answer with
firm prices, you accept one and the trade executes bilaterally at that price.
On a barrier market the requester is always the holder: BUY is long (knocked
out at or below the barrier), SELL is short (knocked out at or above); makers
quote the entry price, holder margin is the premium (the entry to barrier
distance times quantity times the market's premium share: the full distance
less the knock-out rebate, 90 percent on every KO market listed today, or the
strict share, 50 percent, on a Strict TP contract), a guaranteed stop AT the
barrier, and contracts settle at the barrier on knock-out (the holder loses
exactly the premium), at mark on expiry (floored at minus the premium; a
Strict TP contract forfeits its whole premium at expiry without a touch), or
at the writer's quoted price when the holder asks for an early close
(revision 3.44).

- **Trader ID (revision 1.5):** once your member has registered Authorised Users
  with the venue, every RFQ write on this tab (a request, a quote, an acceptance,
  a swap offer or take) needs the Trader ID of the Authorised User entering it,
  exactly as on the API: the field at the top of the tab is held for the session
  and applied to every RFQ write, a missing or unknown id answers "reg.traderId
  missing or not a registered Authorised User" (code 2021), and cancels never
  need it. The note beside the field says whether it is required; a member
  with no registered Authorised Users may leave it empty, and an empty field
  sends nothing.
- **Request quotes:** symbol, side, quantity, quoting window in seconds, an
  optional client UID (brokers), and on barrier markets the barrier level, an
  optional take profit, an optional contract expiry in UTC and, where the
  market offers it, a **Strict TP** toggle (shown with the strict premium
  share; it needs a take profit and an expiry at most 24 h ahead). Your
  request card under My requests shows the premium (indicative at the current
  mark until a quote is accepted) and its share of the distance.
- **My requests:** incoming quotes best first, each with a validity countdown.
  Accept executes immediately at that price after a confirmation. You can
  cancel a request while its window is open.
- **Open requests:** requests from other members you are eligible to quote.
  Enter a price and a validity in seconds, or withdraw a quote you sent.
- **Barrier contracts:** your live contracts with role, direction, entry,
  barrier, take profit, premium (the holder's maximum loss, with its share of
  the distance and a Strict TP badge on strict contracts), mark, knock-out
  distance, unrealised PnL, margin, expiry and client.
  On a live contract you HOLD, **Close early** sends a close request to the
  contract's writer (no side or quantity to enter: the venue derives the
  closing side and the full quantity); the row then says "close requested"
  with the request id, and the writer's quote arrives under My requests where
  Accept closes the contract at that price. Recently settled rows show the
  reason: knock-out, take profit, expiry, or **Closed early** for a close
  request accepted at the writer's quote (maker/taker fees like the entry).
  Only the writer sees a close request; a contract that terminates first
  cancels its open close request automatically.

The tab refreshes every 2 seconds; a quote you are typing is never wiped by a
refresh.

## 5. Orders

Working orders (with remaining quantity, client attribution and your order
reference) and conditional, not yet triggered orders (type, trigger price and
source, limit price or market). Refresh on demand, and the same kill switch as
on Overview. This tab places no orders: orders on DLT markets are entered and
cancelled from the DLT Market tab (section 10a), and every other kind trades
through the Member API only (revision 1.6 states it here).

## 6. End clients

Per end client sub-positions are exact reporting records under the venue's DMA
model: margin and liquidation run on your member NET position, these records
drive attribution and reconciliation. The tab shows live client sub-positions,
lifetime funding attributed per client sub-position (filter by instrument or
client UID, CSV download), and 30 day activity per client. Clients with no
open position in a market are not listed there: their funding has already
settled into your balance and appears in the funding statement under History.

## 7. History

Filter by instrument and date range (dates are UTC). Three statements, each
with a CSV download: trades (price, quantity, fee, role, venue flags, client
attribution), ledger (every balance movement with the running balance after),
and funding payments (one row per settlement, amount signed from your side,
with the rate and the mark the venue used).

## 8. Reports

Reports are generated from the venue's durable records and can briefly trail
the live sequence in the header. Timestamps are UTC, values exact decimal
strings, CSV downloads cap at 50,000 rows; narrow the date range for a
complete export. Available: trade history CSV (7 days, 30 days, or all),
account ledger CSV, activity statistics as JSON (30 or 90 days), and a pointer
to the end of day client position snapshot served on the member API for
reconciliation.

Monthly statements (since 18 August 2026): a "Monthly statements" card lists
your formal member statement for every CLOSED month, produced by the venue
after month end from its journaled ledger and trade records, downloadable as
PDF and CSV. Each statement carries the opening and closing balance per
currency with cash in and out, the ledger totals by kind (FEE rows are the
venue charges), the activity per market (maker and taker trades, volume,
notional, fees, realised PnL including auto-deleveraging closes, funding paid
and received) and the margin figures captured at the period end with the
unrealised PnL at that point. The current month is not a statement yet. The
document is the same one the venue's operations hold for you; its listing
shows the SHA-256 of the PDF so a downloaded copy can be verified against it.
Since revision 1.5: the statement is issued per engine account and never
consolidated across your accounts; its header names the operator's registered
office (and licence number where shown) under "Kronos X, PM MTF Ltd"; it
carries the fixed sentence on the safeguarding of Member funds under the
Rules; and a **Signature** link beside PDF and CSV serves a detached Ed25519
signature over the PDF bytes, to verify against the venue's published
verification key (Regulatory tab). If the venue has not configured signing,
the link is absent. Statements stay downloadable here for seven years from the
date the venue produced them (revision 1.5).

## 9. Regulatory

Venue-attributable data only, aggregated by you across venues, not regulatory
or legal advice. The tab shows your capacity enforcement stage and permitted
trading capacities, capacity coverage over 30 days, the data basis (sequence
and parameter version), the rolling K-DTF and K-COH venue-attributable figures
with their windows and coefficients, and the daily flow series: executed value
per UTC day split by the trading capacity your orders carried (DEAL and MTCH
to dealing on own account, the K-DTF input; AOTC to client orders handled, the
K-COH input). The nightly aggregation runs after 00:00 UTC. The rolling
figures average over every calendar day of their window at the 00:00 UTC
boundary, a day without fills counting as zero, unless the venue has put the
Cyprus Business Day calendar in force (next paragraph); the venue lists no
non-trading day, so no day is excluded or moved to another day, which is the
lower of the two possible readings, and if your own computation runs on a
business-day calendar you rebase from the 400-day CSV, which covers the whole
K-DTF window.

Measurement calendar (revision 1.5): each rolling card's window line reads
"(N Business Days)" when the venue has put the Cyprus Business Day calendar in
force (Member API section 6f: a day other than Saturday or Sunday on which
commercial banks in Cyprus are open for general business) and "(N days)" while
the means divide by every calendar day; under the Business Day calendar a
further line, "Cyprus bank holidays applied: ...", lists the holidays the
divisor and the roll-forward attribution applied to that window. The daily
flow table below stays per UTC calendar day either way. A measure the venue's
parameter store does not resolve shows its PARAMETER_ERROR text in place of the
figure; tell venue operations.

Downloads: the daily flow series as CSV (90 or 400 days) and the monthly IFR
data annex for a calendar month you pick. The annex carries the daily series,
the rolling averages, the coefficient application, the coverage, the parameter
version used and, when the venue captured one for the month-end day, your
month-end K-TCD exposure snapshot with its methodology note: the note explains
every column and the two collateral views, the supervisory-factor class per
market and the view B haircut per balance as signed off in the venue parameter
store at the snapshot's parameter version, and that barrier contracts are
excluded and shown as the memo column; the venue expresses no view on whether
any collateral may be recognised under the IFR (Member API reference section
6f). The **Signature**
button downloads a detached Ed25519 signature over the exact annex bytes;
verify it against the venue's published verification key. If the venue has not
configured annex signing, the portal says so.

Verification key (revision 1.5): the line beside the Signature button names the
key, `Verification key: Ed25519, key id <keyId>, public key <base64>`. The key id
is the first 8 lowercase hex characters of SHA-256 over the raw public key, a
label for your key table; the key and the signatures are unchanged. Every annex
and `.sig` download carries the key id in the response header
`X-KronosX-Annex-Key-Id` beside the signature header
`X-KronosX-Annex-Signature-Ed25519`; both reach an HTTP client through the
portal, while a browser download stores the body only. The verification
procedure, the key table and a worked example are in the Member Technical
Handbook, section 12a.

## 10. API and limits

- **API credentials:** up to 5 keys per scope (TRADE and READ_ONLY). Issuing a
  key ADDS it alongside your existing keys; nothing stops working when you
  issue. Each secret is shown exactly once, in the dialog at issuance, and can
  never be retrieved again: store both values before closing it. Revocation is
  immediate and per key: the revoked key stops authenticating at once and live
  WebSocket and FIX sessions signed with it are cut; your other keys keep
  working. Migrate integrations key by key: issue, move traffic, then revoke.
- **Portal password:** self-service change, see Signing in.
- **Authorised users (Trader IDs):** registered by venue operations (rulebook
  5.10). If enforcement is active and every user is deactivated, order entry
  is locked. Once a user is registered, RFQ writes on the portal need the
  Trader ID too: enter it in the field at the top of the RFQ tab (revision
  1.5, section 4).
- **Rate limits and order-to-trade regime:** your class, your orders per minute
  and reads per minute and, where your class publishes one, the per-second
  ceiling on order entry, and the sliding 60 minute order-to-trade window with
  its warn and block thresholds. A block rejects new orders, batches and
  amendments; cancels always pass. These figures apply to the DLT Market order
  ticket (section 10a) exactly as to the API: an order entered on the portal
  debits the same order-entry budget as your API keys and counts under the
  order-to-trade regime of its market, and a cancel from the ticket counts as an
  order message like a cancel over the API (revision 1.6).
- **Engine limits:** maximum open orders, any per-member order quantity
  override, and your initial margin multiplier.
- **Your own limits (revision 1.4):** limits you set yourself, account-wide or for
  one market: a smaller open-order, order-size, position, open-RFQ or open-contract
  cap, a tighter price band or market-order collar, a larger initial margin
  multiplier. Pick the scope (account, or one market), the parameter and a value,
  then Set; Clear returns a parameter to the venue's rule. The table shows, per
  parameter, the value in force with the scope that supplies it (the market rule,
  a value venue operations set for you, or your own) and your own stored value. A
  value of yours can only TIGHTEN what is in force: the venue refuses a looser one
  and shows the reason. Values you set here are the same as
  `PUT /v1/account/parameters` on the API and are yours to clear again; venue
  operations never edit them.
- **Documentation:** links to the interactive API console and the OpenAPI
  document.

## 10a. DLT Market (revision 1.5)

The DLT Market tab shows the tokenised securities (shares and bonds) that
settle on the Kronos X chain, the venue's permissioned ledger under Regulation
(EU) 2022/858, and lets you trade them from the browser. It is the trading
screen of a direct participant (a natural or legal person admitted to trade on
its own account) and a convenience for any member with access to SECURITY
markets; API integrations use the same markets through the Member API.

- **Cards:** the ledger height and whether the head is attested, the number
  of DLT markets you are eligible for, the units you hold in trading (the
  mirror of the chain's locked holdings) and the number of wallets.
- **Order ticket:** pick the market, the side, the time in force (GTC, GTD,
  IOC, FOK), the limit price and the quantity in units (one unit is 1/unitScale
  of a share; the market line under the ticket states it), optionally the
  client identifier of the end client (blank means your house account). Only
  LIMIT orders are accepted on this ticket. A SECURITY market is prefunded: a
  sell needs the units in trading, a buy needs the settlement currency on your
  account; the venue rejects otherwise with the ordinary codes. On a market
  with a call auction the line shows the trading phase and the call times;
  during a call or while closed an IOC or FOK order is refused with code 2046
  and a GTC or GTD order rests for the uncross. The ticket places the same
  order as `POST /v1/orders` under your member's engine account, subject to
  the same rules as the API (revision 1.6): the Trader ID rule (once your
  member has registered Authorised Users the order must carry one, code 2021;
  the session-held Trader ID field of the RFQ tab, section 4, rides on every
  DLT order too), the same order throttle and order-to-trade counter, the
  same capacity rule and your own order and position limits; the markets
  listed are the SECURITY markets your member is eligible for. Other market
  kinds are not tradable from the portal.
- **Order book:** the ten best levels of the picked market, refreshed every
  few seconds while the tab is open.
- **Working orders:** your resting orders on DLT markets with a Cancel button.
- **Wallets:** one custody wallet per client identifier you traded or
  registered plus your house wallet and any external wallet you sponsor, with
  free units (held outside trading) and units in trading per instrument. A
  client wallet is created at the client's first fill.
- **Settlement obligations:** every fill on a DLT market with its state
  (Pending, Settled, Failed), the block height and the transaction hash once
  final; the transaction can be looked up on the public explorer.

## 11. Inquiries

Venue operations may open an inquiry with your firm, for example a KYC
refresh, a settlement question or a reconciliation request. Each inquiry is a
message thread: the list shows id, title, status, message count and the last
message time; click a row to read the thread. The venue's messages appear on
the left under the Kronos X label, your replies on the right. You can reply
while the inquiry is OPEN; a CLOSED inquiry is read only. Replies are recorded
by the venue for audit. The Inquiries tab button shows a count of your open
inquiries from the moment you sign in.

## 12. Onboarding

The Onboarding tab is visible only until venue operations mark your firm as
onboarded; members onboarded manually outside the portal never see it. A
portal login works before onboarding: onboarding state never gates the login,
your API keys or any other portal function.

- **Status:** NOT_STARTED, IN_PROGRESS (a draft is saved), or SUBMITTED,
  shown as "submitted, under review by the venue".
- **Form:** legal name, LEI, registered address, country, contact name, email
  and phone, regulatory status (free text, for example licensed investment
  firm, or unregulated), and notes for the venue.
- **Save draft** stores your entries without submitting. **Submit for review**
  hands the record to the venue; you can keep editing and resubmit until the
  venue decides. The venue may leave a note on your record, shown above the
  form, asking for specific items.
- **Documents:** upload files of up to 8 MB each, at most 30 files and 64 MB in
  total per member. Accepted formats (revision 1.6 states them here) are PDF
  (not password protected or encrypted), PNG, JPEG, modern Office documents
  (.docx, .xlsx, .pptx without macros) and plain text (.txt, .csv, .json);
  legacy Office files (.doc, .xls, .ppt), SVG, archives, macro-enabled Office
  files and any other type are refused, with the reason shown beside the
  Upload button. The venue keeps a rebuilt copy of every accepted file:
  metadata and any active content (scripts, macros, embedded objects) are
  removed and the stored type is taken from the file's own content, so a
  document you download from the list can differ byte for byte from the file
  you uploaded while showing the same content. Uploaded documents are listed
  with size and time and can be downloaded by clicking the name. They remain
  part of the venue's onboarding record. Every document is inspected before it
  is stored; a file the venue cannot make safe is refused with the reason (an
  encrypted PDF, an Office document that links external content or carries a
  macro, a document too large to inspect). The inspection is bounded: a file
  that exceeds the inspection budget is refused with "inspection budget
  exceeded; upload a smaller or flattened document", and while the venue is
  inspecting other uploads yours may be answered "the document inspection
  service is busy; retry in a few seconds", or, when a previous upload of yours
  is still being inspected, "an upload of yours is still being inspected; retry
  in a few seconds": retry after a few seconds.

Once venue operations complete your onboarding the tab disappears and the
venue's record is authoritative.

**Additional member accounts (subaccounts).** Your firm holds one main member
account and may, on request and on the same terms as every other member, hold
further member accounts under its membership. Ask venue operations (your
onboarding contact, or an inquiry under section 11) and name the purpose, for
example the rulebook's Position Margin election or a segregated account per
trading capacity. Each additional account is a full member account with its own
code (your code plus a numeric suffix, for example ACME-2), its own API keys,
portal login and authorised users, and is margined, liquidated, reported and
limited on its own: the collateral you deposit to it backs only the positions
and orders held there and is not available to any other account of yours, and
collateral moves between your accounts only by withdrawal and deposit. Before
the first trade venue operations record the account's regulatory profile
identical to your main account's (LEI, permitted capacities, transaction
reporting status) and carry over your class assignments and any measure in
force, and a measure under the Rules applies to all of your accounts.
Self-trade prevention does not apply between your accounts: an order from one
of your accounts can match an order from another, and a cross between the same
end client on two of your accounts is screened by the venue's surveillance like
any other same-client cross.

## 13. FAQ

**The Onboarding tab has disappeared. Is something wrong?** No. The tab is
removed once venue operations mark your firm as onboarded; that is the normal
end of the process. Members onboarded outside the portal never see the tab at
all. Nothing else in the portal changes.

**Why is an inquiry read only?** The venue has closed it. Closed inquiries
stay visible for your records but no longer take replies. If the matter needs
to continue, contact venue operations and they will open a new inquiry.

**A report and the header sequence disagree. Which is right?** Both. Reports
come from the venue's durable records and can trail the live sequence by a
moment; they catch up on their own.

**I lost an API secret.** Secrets are shown once and never retrievable. Issue
a new key, move your traffic, then revoke the old one; nothing stops working
until you revoke.

**Who do I contact?** Venue operations of PM MTF Ltd, via the contacts in your
membership agreement and onboarding pack. For anything you suspect is a
security matter (compromised password, unexpected session), contact them
immediately.