FMA Guidance 2017/19: MiFIR Reporting Moves to a REST Interface

On 6 November 2026 the Financial Market Authority Liechtenstein (FMA) announced a revised FMA Guidance 2017/19 on the reporting obligation for transaction data under Article 26 MiFIR. The SOAP interface that reporting parties use to send transaction reports to the FMA will be replaced by a REST interface, after a three-month testing phase in 2027.

The FMA states that the transaction reporting data formats currently in use and certificate-based authentication remain unchanged. The guidance change log records one entry for 3 November 2026: an adjusted annex, now the OpenAPI Interface Specification for Transaction Data Reporting (3rd revised version, as at September 2026). For a MiFIR transaction reporting team in Liechtenstein, the work is a new client to build and test, with new endpoints, new status calls and duplicate rules that apply to every resend and correction.

Related reading: MiFIR Transaction Reporting: Complete Guide to Article 26 Compliance

FMA Guidance 2017/19 revision: the dates to plan around

• 3 January 2018: FMA Guidance 2017/19 issued and in force.
• 3 November 2026: latest amendment, recorded in the change log as an adjustment of the annex interface specification.
• 6 November 2026: FMA notice announcing the replacement of the SOAP interface by a REST interface.
• 1 February 2027 to 30 April 2027: testing phase for the new connection.
• 1 May 2027: planned go-live.

The FMA calls 1 May 2027 a planned date, so it can still move. It also falls on a Saturday. The first weekday after go-live is Monday 3 May 2027, which on a normal working-day calendar is also the T+1 deadline for transactions executed on Friday 30 April 2027.

What stays the same for Article 26 reporting in Liechtenstein

The obligation sits in Article 26(1) of Regulation (EU) No 600/2014 (MiFIR): investment firms that execute transactions in financial instruments report complete and accurate details to the competent authority as quickly as possible and no later than the close of the following working day. The German text of the guidance restates this as T+1 and cites Article 26 MiFIR and Delegated Regulation (EU) 2017/590 (RTS 22) as its legal basis. The 6 November notice changes none of that.

The message set carries over too. The annex keeps the ESMA ISO 20022 schemas: auth.016.001.01 (ESMAUG_Reporting, version 1.1.0) for transaction reports and auth.031.001.01 for feedback, wrapped in the Business File Header (head.003.001.01) and the Business Application Header (head.001.001.01). Files are checked against the schema and against ESMA and FMA validation rules, with the ESMA rule set linked from the annex as the ESMA65-8-2594 file.

The FMA states that the data formats in use remain unchanged, so the notice itself gives no sign of field remapping; the revised annex is the document to check against. Field-level reform runs on separate tracks, covered in our article on ESMA’s transaction reporting simplification report and, for the distinct UK MiFIR regime, in our note on the FCA’s PS26/15 reform. The FMA notice mentions neither.

Who has to rebuild the connection

The guidance is addressed to investment firms under the Investment Firms Act (WPFG), banks under the Banking Act (BankG), asset management companies under the Asset Management Act (VVG) and market operators under the Handelsplatz- und Börsegesetz (HPBG). Market operators have a reporting role of their own: Article 26(5) MiFIR requires the operator of a trading venue to report details of transactions in financial instruments traded on its platform that are executed through its systems by a firm not subject to MiFIR.

Regulation (EU) 2024/791 amends Article 26(5) MiFIR at EU level to refer to any member, participant or user not subject to the Regulation. However, ESMA’s public statement of 27 March 2024 says the MiFIR rules in force before the review and RTS 22 continue to apply to transaction reporting until the revised RTS start applying. Separately, EFTA’s EEA-Lex entry records a draft Joint Committee Decision on Regulation (EU) 2024/791 as under consideration, so its incorporation into the EEA Agreement is pending. On that basis the amended wording does not yet change which transactions trading-venue operators report under Article 26(5).

The guidance applies its technical requirements to every reporting party that transmits data to the FMA.

The REST client is built by whoever sends the file. Article 26(7) MiFIR allows reports to be made by the investment firm itself, by an approved reporting mechanism (ARM) acting on its behalf, or by the trading venue through whose system the transaction was completed. The annex identifies the submitter through its own client certificate, and the SubmittingParty in each transaction has to match that identity.

Article 26(7) also keeps the investment firm responsible for the completeness, accuracy and timeliness of its reports when another party transmits them. The exception covers failures attributable to an ARM or trading venue reporting on the firm’s behalf, and the firm must still take reasonable steps to verify those reports. Under the annex, each submitter can view only its own feedback. On this reading of the annex, a firm whose reports are sent by another entity sees the FMA’s validation results only through that submitter, so the feedback hand-off belongs in the outsourcing arrangement before testing starts.

The REST build: endpoints, transport and file rules

The new Data Reception Interface (DRI) is a REST API over HTTPS, described in an OpenAPI document in JSON attached to the guidance. The annex lists five endpoints:

Two environments are operated: integration (testing) at https://dri-int.fma-li.li/v1/ and production at https://dri.fma-li.li/v1/. The annex says the host names remain unchanged while the paths follow the REST pattern /v1/. The connection uses mutual TLS with an FMA-issued X.509 client certificate, with TLS 1.2 as the minimum and TLS 1.3 supported.

The report goes in as multipart/form-data inside a ZIP archive; a submission not sent as multipart/form-data returns HTTP 415. The archive must contain exactly one XML file (FIL-102), and the uncompressed file may not exceed 1024 MB (LIX-002, HTTP 413). Errors come back as RFC 9457 Problem Details with an FMA errorCode and a fileStatus of RJCT (rejected), CRPT (unreadable or corrupted) or RMDR (a notice; the file is not rejected). FIL-104 rejects a file whose message identifier in the Business Application Header does not refer to the latest approved schema.

One SOAP-era parameter disappears. The guidance change log for 14 June 2018 records that the SOAP operation passed the sending entity’s LEI in a parameter that kept the name executingEntityLei. The annex states that the REST call needs no separate LEI parameter, because the client certificate identifies the submitter. A report whose submitting entity does not match that certificate fails with LIX-003 and HTTP 403.

Submission status and daily feedback under the new interface

An HTTP 201 Created response confirms that the FMA accepted the submission as a file. It returns a submissionId, the MD5 hash of the decompressed XML and the number of transactions read, which the annex treats as a plausibility check against the submitter’s own count. At file level the submission then moves from RECEIVED (not yet validated) to ACPT, PART or RJCT, retrieved through GET /v1/submissions/{id}. A file that fails the initial technical validation is rejected in full and not stored.

Transaction-level results arrive separately. Each transaction ends up ACPT, RJCT or PDNG in the daily auth.031 feedback, and PDNG transactions are revalidated daily for up to seven calendar days before reaching a final ACPT or RJCT. A control that marks transactions as accepted on the 201 response records the wrong event, because acceptance sits in the feedback.

Feedback is a pull model. The FMA generates one feedback file per day for each submitter LEI, covering that day’s submissions and any earlier PDNG transactions whose status has changed. GET /v1/feedbacks lists available dates in descending order, with optional from, to, pageSize and afterId filters, and GET /v1/feedbacks/{date}/file returns either the auth.031 message or a time-limited download URL, so the poller has to handle both.

Duplicates, resends and the Business Message Identifier

The Business Message Identifier in the Business Application Header follows the format LI_<SubmittingPartyLEI>_<YYYY>_<sequenceNumber>: country code LI, the 20-character LEI of the submitting party, the current reporting year and a consecutive positive sequence number. LIX-008 rejects a wrong format.

The DRI rejects a submission as a duplicate (HTTP 409) in two cases: the MD5 hash of the decompressed XML matches an earlier file (LIX-004), or the Business Message Identifier has already been used (LIX-007). The response’s duplicateOf field then points to the original submission, which is why the annex says an interrupted transmission can be resent safely.

The annex (section 4.2) defines the duplicate test by the MD5 hash of the decompressed XML, so on that wording re-zipping the same XML under a new archive name should still match the earlier file. A corrected file needs a new Business Message Identifier, since reusing the old one triggers LIX-007 even when the content has changed. Within a file, LIX-009 allows at most one occurrence of a unique transaction identifier per transaction reporting type (New or Cancellation). The FMA’s published transaction-reporting FAQ (Transaktionsmeldungen, MiFID II) requires the sequential component of the Business Message Identifier to be reset at the turn of every year, so the identifier generator must restart the sequence for each new calendar year. The same FAQ applies the identifier convention to the XML file name and sets no naming convention for the ZIP container.

Certificates and the e-Service Portal

Credentials still come from the FMA e-Service Portal, where an FMA-approved superuser (registered through eID.li, with the application signed by authorised signatories) generates them as a ZIP file of certificate and key files, with the password sent by email. The download dialog appears once; downloading again generates new credentials.

Certificates are valid for three years. Twelve weeks before expiry the certificate turns red in certificate management and every superuser of the reporting entity receives an email; after expiry the system deactivates it, and a deactivated certificate is rejected on submission. An active LEI is required for Article 26 reporting and has to be notified to the FMA via amm@fma-li.li, the address both language versions of the annex give; section 5.2 of the English version also lists Meldewesen.AMM@fma-li.li. The e-Service Portal supports certificate issuance, renewal and deactivation. The annex screenshot of the generation dialog indicates that existing active certificates for the same LEI stay active when a new one is generated; whether earlier certificates are compatible with the REST endpoints should be verified during integration testing.

Frequently Asked Questions

Will the SOAP interface stay available during the testing phase?

The notice says SOAP will be replaced and gives the testing window and the planned go-live, and the annex assigns testing to the integration environment. Neither the notice nor the change log sets a separate SOAP switch-off date or a parallel-run rule, and the annex reserves the FMA’s right to amend the document and the interface. The guidance names the FMA’s Asset Management and Markets division (amm@fma-li.li) as its contact.

Can one group entity submit reports for several Liechtenstein entities?

The annex allows each sending entity to submit delegated reports with its own credentials and states that sharing credentials is not required. The SubmittingParty in every transaction must match the entity identified by the certificate (LIX-006), while the executing entity is identified in the report fields, as RTS 22 already requires. Article 26(7) MiFIR still sets the routes for making the reports: the investment firm itself, an ARM acting on its behalf, or the trading venue through whose system the transaction was completed.

Does a certificate already in use for SOAP need replacing before testing?

The FMA states that certificate-based authentication remains unchanged, and the annex keeps the e-Service Portal process for issuing certificates. It does not say in terms that a certificate issued before the revision works against the new endpoints. On a plain reading, “unchanged” covers existing credentials, which the integration environment can confirm early in the testing window.

Related Articles

• MiFIR Transaction Reporting: Complete Guide to Article 26 Compliance: the Article 26 obligation, in-scope instruments, RTS 22 fields, reporting routes and deadlines.
• Transaction Reporting Simplification: ESMA’s EUR 1bn Plan: ESMA’s July 2026 report on simplifying EMIR, MiFIR and SFTR reporting.
• UK Transaction Reporting Reform: 65 Fields Cut to 52 by 2028: how the FCA’s PS26/15 reshapes UK MiFIR transaction reporting.

Key Takeaways

• Name the REST client owner now: feedback is visible only to the entity whose certificate submits.
• Flag transactions as accepted from auth.031 feedback, never from the 201 response; keep PDNG items open.
• Treat resends and corrections differently: an identical resend gets a 409 pointing to the original; a correction needs a new Business Message Identifier, and the sequence restarts each calendar year.
• The FMA says data formats remain unchanged, so plan the work in the transport layer and confirm the RTS 22 mappings and the auth.016.001.01 build against the annex in the integration environment.
• Check certificate expiry against the cutover, verify the behaviour of newly generated and existing certificates in integration testing, and deactivate superseded credentials through the FMA’s certificate-management process.

Sources and References

• FMA, FMA Guidance 2017/19 on the Reporting Obligation for Transaction Data under Article 26 MiFIR revised (news, 6 November 2026): fma-li.li
• FMA, FMA-Wegleitung 2017/19: Meldepflicht von Transaktionsdaten (issued 3 January 2018, last amended 3 November 2026): PDF (German)
• FMA, OpenAPI Interface Specification for Transaction Data Reporting, 3rd revised version, as at September 2026 (annex to FMA Guidance 2017/19): PDF (English) and PDF (German)
• FMA, Transaktionsmeldungen (MiFID II), e-Service FAQ: fma-li.li
• Regulation (EU) No 600/2014 on markets in financial instruments (MiFIR), Article 26: EUR-Lex
• Regulation (EU) 2024/791 amending Regulation (EU) No 600/2014 (MiFIR review), Article 26(5) as amended: EUR-Lex
• EFTA, EEA-Lex entry for Regulation (EU) 2024/791 (EEA incorporation status): efta.int
• ESMA, Public Statement: Transition for the application of the MiFID II/MiFIR review (27 March 2024, ESMA74-2134169708-7163): PDF
• Commission Delegated Regulation (EU) 2017/590 (RTS 22) on the reporting of transactions to competent authorities: EUR-Lex
• ESMA, MiFIR transaction reporting ISO 20022 XML schemas (ESMA65-8-2598, Annex 2), as linked from the FMA annex: ZIP
• ESMA, MiFIR transaction reporting validation rules (ESMA65-8-2594, Annex 1), as linked from the FMA annex: XLSX
• ESMA, Guidelines on transaction reporting, order record keeping and clock synchronisation under MiFID II (ESMA/2016/1452): PDF
• FCA, PS26/15: Improving the UK transaction reporting regime: fca.org.uk

Before the 1 February 2027 test window opens

The build list follows from the annex and the FMA’s FAQ: a REST client generated from the OpenAPI document, a Business Message Identifier generator in the LI_ format that issues a fresh identifier for every corrected file and restarts its sequence each year, a poller that keeps file-level and transaction-level status apart, and a check that the FMA client certificate and the notified LEI stay valid through the cutover. Testing opens on 1 February 2027 against https://dri-int.fma-li.li/v1/, and production on the REST interface is planned for 1 May 2027.

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.