# FSRA venue reports

Source: https://docs.settlemint.com/docs/concepts/records-and-evidence/fsra-venue-reports
Which venue report columns hold the MIR 3.6.7 post-trade details, and the provisional FSMR s.149 files an ADGM venue sends the FSRA.

A multilateral trading facility (MTF) in the Abu Dhabi Global Market (ADGM) answers to the Financial Services Regulatory Authority (FSRA) under two sets of rules. The Market Infrastructure Rules (MIR) 3.6.7 name the details of each trade that the venue makes public and gives to the regulator. Section 149 of the Financial Services and Markets Regulations (FSMR) obliges the venue to report its orders and transactions to the FSRA. The venue matched trades report has a column for every MIR 3.6.7 detail. Two draft [reporting obligations](https://docs.settlemint.com/docs/concepts/records-and-evidence/reporting-obligation) generate the s.149 files in a provisional layout, because the FSRA has published no specification for them. The platform generates the files. The MTF operator uploads each one to the FSRA, records the FSRA's acknowledgement on the filing, and stays responsible for meeting both rules.

Note (The s.149 layout is provisional): The FSRA publishes the s.149 duty but no rules on what a report holds or how it is filed: FSMR s.149(5) lets the FSRA make such rules, and none are in the current rulebooks. The s.149 layout below is provisional, modelled on MiFIR RTS 22 and RTS 24 until the FSRA specification is confirmed. RTS 22 is the European transaction reporting standard and RTS 24 the European standard for the order records a venue keeps. The field list, the cadence and the deadline are all settings on the obligation, so a confirmed specification that fits those settings replaces them with a new obligation version.

## Post-trade fields under MIR 3.6.7 [#post-trade-fields-under-mir-367]

The venue matched trades report holds one row for each trade matched on the reference day, including a trade later undone at delivery. MIR 3.6.7 names seven details, and MIR 3.6.2 adds three indications. Each one has a column in the report.

| Rule | Detail | Column | What the column holds |
| --- | --- | --- | --- |
| MIR 3.6.7(a) | Trading day | `tradingDay` | The date of the venue session the trade was executed in. A trade outside any session is dated in the instrument's time zone, then the venue's, then UTC. |
| MIR 3.6.7(b) | Trading time | `executedAt` | The execution time in UTC, to the millisecond. |
| MIR 3.6.7(c) | Instrument identification, provisional | `instrumentId` | The instrument's ISIN when its token metadata holds a valid one under the key `isin`. Otherwise the venue's own instrument ID. |
|  |  | `instrumentIdType` | `ISIN` or `VENUE`, naming which of the two `instrumentId` holds. |
| MIR 3.6.7(d) | Unit price | `unitPrice` | The price of one whole unit of the instrument in whole units of the quote asset, without fees, exact to 18 decimal places. It is empty while the platform does not know the decimals of either token. |
| MIR 3.6.7(e) | Price notation | `priceCurrency` | The currency the quote asset is priced in, as an ISO 4217 code. When the quote asset has no price currency, the column holds its symbol. |
| MIR 3.6.7(f) | Quantity | `unitQuantity` | The number of whole units traded. It is empty while the instrument's decimals are unknown. |
| MIR 3.6.7(g) | Venue identification | `venue` | The venue's identifier on the platform, or its contract address when the venue has no configuration record. |
| MIR 3.6.2(b) | Price set by factors other than the market | `nonMarketValuationFlag` | Always `false`. The venue matches orders only on its order book, so it has no portfolio trades and no volume-weighted average price trades. Review the flag if the venue adds a trading facility. |
| MIR 3.6.2(c) | Negotiated trade | `negotiatedTradeFlag` | Always `false`. The venue has no facility for negotiated trades. |
| MIR 3.6.2(d) | Amendment of a disclosed trade | `recordStatus` | `NEWT` for a trade, `CANC` for a trade undone at delivery, which cancels the record published for it. |

The columns `priceTick` and `quantity` hold the venue's own integer price step and base-unit quantity.

Note (The instrument identifier is provisional): MIR 3.6.7(c) asks for "a unique code to be decided by the Regulator". The FSRA has not named that code, so the ISIN, with the venue's own instrument ID as a fallback, is a provisional choice. `instrumentIdType` tells a reader which scheme each row uses.

The venue orders report carries the same instrument and price columns for each order: `instrumentId`, `instrumentIdType`, `unitPrice` (the limit price, empty for a market order), `priceCurrency`, `unitQuantity`, `filledUnitQuantity`, `remainingUnitQuantity` and `venue`.

## The FSMR s.149 order and transaction reports [#the-fsmr-s149-order-and-transaction-reports]

The platform catalogue holds two draft obligations under the regime "FSRA order and transaction reporting (FSMR s.149)". Each organisation receives its own draft copy of both, as it does for every catalogue entry. Review the copy, set the values that name your venue, and publish it from [Obligations](https://docs.settlemint.com/docs/console/reporting/obligations).

| Obligation | Report it reads | Authority file | Modelled on |
| --- | --- | --- | --- |
| FSRA s.149 transaction report (provisional) | Venue matched trades | `fsra-s149-transactions.csv` | MiFIR RTS 22 transaction reports |
| FSRA s.149 order report (provisional) | Venue orders | `fsra-s149-orders.csv` | MiFIR RTS 24 order records |

Both share one schedule and one completion rule:

- **Cadence.** Daily. The platform generates the filing once the reference day closes on the obligation's calendar, and lists rows only when a venue session closed that day.
- **Deadline.** The draft sets one business day on the ADGM calendar after the reference day, by 23:59 Asia/Dubai. This is a setting on the obligation, not an FSRA rule.
- **Ending.** The filing ends when a user records the FSRA's acknowledgement on it. A filing with no acknowledgement recorded within 24 hours of its recorded submission turns unacknowledged.
- **Empty days.** A day without a closed session still produces a filing, with no data rows. The obligation accepts it as a nil return.
- **File.** UTF-8 CSV with a header row, separated by commas, with no byte order mark and LF line endings.
- **Filer.** The "Reporting entity LEI" on the obligation, and the `SubmittingEntityId` column, hold the MTF operator's LEI.

Note (Fill in your identifiers): The catalogue leaves the "Reporting entity LEI" empty and puts placeholders in the authority file columns: `REPLACE-WITH-OPERATOR-LEI` in `SubmittingEntityId`, and `REPLACE-WITH-VENUE-MIC` in `Venue` and `TradingVenue`. A copy published unchanged files reports with those placeholders and no reporting entity LEI. Before you publish, enter the MTF operator's LEI in the "Reporting entity LEI" and in `SubmittingEntityId`, and your venue's MIC in `Venue` and `TradingVenue`.

### Transaction report columns [#transaction-report-columns]

One row per matched trade of the reference day.

| Column | Value |
| --- | --- |
| `ReportStatus` | `NEWT`, or `CANC` for a trade undone at delivery |
| `TransactionReferenceNumber` | The trade ID |
| `TradingVenueTransactionId` | The trade ID |
| `SubmittingEntityId` | The MTF operator's LEI, fixed text |
| `BuyerId` | The buyer's account on the venue |
| `BuyOrderId` | The buy order ID |
| `SellerId` | The seller's account on the venue |
| `SellOrderId` | The sell order ID |
| `TradingDateTime` | The execution time in UTC, such as `2026-04-01T11:00:00.000+00:00` |
| `TradingDay` | The trading day |
| `Quantity` | The number of whole units traded |
| `Price` | The unit price |
| `PriceCurrency` | The price currency, upper case |
| `Venue` | The venue's MIC, fixed text |
| `InstrumentId` | The ISIN, or the venue's instrument ID |
| `InstrumentIdType` | `ISIN` or `VENUE` |

### Order report columns [#order-report-columns]

One row per order placed on the reference day, with its state at the end of that day. The report does not list each event in an order's life, as an RTS 24 record would.

| Column | Value |
| --- | --- |
| `SubmittingEntityId` | The MTF operator's LEI, fixed text |
| `TradingVenue` | The venue's MIC, fixed text |
| `OrderId` | The order ID |
| `MemberId` | The account that placed the order |
| `InstrumentId` | The ISIN, or the venue's instrument ID |
| `InstrumentIdType` | `ISIN` or `VENUE` |
| `BuySellIndicator` | `BUY` or `SELL` |
| `OrderType` | `LIMIT` or `MARKET` |
| `ValidityPeriod` | `GTC`, `GTD`, `DAY`, `IOC` or `FOK` |
| `LimitPrice` | The limit price per whole unit, empty for a market order |
| `PriceCurrency` | The price currency, upper case |
| `InitialQuantity` | The number of whole units ordered |
| `FilledQuantity` | The number of whole units filled |
| `RemainingQuantity` | The number of whole units not filled |
| `OrderStatus` | The order's status at the end of the day, upper case |
| `EventReason` | Why the order closed, when it closed |
| `OrderSubmittedAt` | When the order was placed, in UTC |
| `LastEventAt` | When the order last changed, in UTC |

### What the provisional layout leaves out [#what-the-provisional-layout-leaves-out]

RTS 22 and RTS 24 ask for fields the venue does not hold, and the provisional layout leaves them out: the buyer's and seller's LEI or national identifier, the decision maker, the trading capacity, short-selling and waiver indicators, and the client identification codes. The buyer, seller and member columns hold the participant's account on the venue instead.

## Replace the provisional layout [#replace-the-provisional-layout]

When the FSRA confirms its specification, edit your copy of each obligation and publish the result as a new version. Filings already made keep the version they were made under.

1. Change the columns, the file name and the CSV settings under "Custom file layout" in the [obligation editor](https://docs.settlemint.com/docs/console/reporting/obligations#edit-the-draft), or send the whole layout through `PUT /api/v2/reporting/obligations/{obligationId}` in the [Platform API](https://docs.settlemint.com/docs/api-reference/v2).
2. Change the cadence and the deadline in the same draft.
3. Publish the draft.

## Rule references [#rule-references]

- MIR 3.6.1 and 3.6.2, post-trade transparency, and MIR 3.6.7, the post-trade information table. COBS 8.2.1 applies them to an MTF operator.
- FSMR s.149(1) and (2), the duty to report orders and transactions, and s.149(5), the FSRA's power to make rules on content and manner.
- MiFIR RTS 22 (Commission Delegated Regulation (EU) 2017/590) and RTS 24 (Commission Delegated Regulation (EU) 2017/580), the models for the provisional layout.

## Related concepts [#related-concepts]

- [Reporting Obligation](https://docs.settlemint.com/docs/concepts/records-and-evidence/reporting-obligation): how a published version freezes the layout, cadence and deadline of a filing.
- [Trade reports](https://docs.settlemint.com/docs/concepts/records-and-evidence/trade-reports): the per-trade reports a venue sends over a FIX session.