Review reporting filings in the DALP Console

Filings lists the attempts your organisation has made to discharge reporting duties. Each row is one submission against a filing period, not the duty itself. Use this screen after Filing calendar tells you a period is due: generate the filing, send it for review, approve it and record how it was completed.

Reading the list changes no filing or asset state. A filing artifact, the set of stored files, can contain holder-level personal data, so only an organisation owner or a platform administrator can download one. Who can do what lists which role gets which control.

Filings table with each attempt's filing state and anchor state — The “Filings” page with a figures strip, filter controls and a table that shows each filing attempt as a row, with its filing state and anchor state.

Before you start

You need a filing to work on. A filing appears once a filing period has been generated against an obligation. Without one, the page reads “No filings yet” and offers Open obligations.
You need a second owner to approve. The person who selected Submit for review is the filing's maker and cannot approve it, so another organisation owner has to. The person who generated the filing is not checked, so an owner who generated it can approve it when someone else submitted it for review. A filing that waits says who can approve it: a viewer who cannot approve reads “Waiting for approval by an organisation owner” with the names of the owners other than the maker.
You need your own session. An impersonated session cannot approve, publish or record an authority receipt.
You need to know where the filing goes. The platform sends no filing file to an authority. You send it through your organisation's channel and record the receipt, or you publish it, depending on the obligation's published version. Trade reports are the exception: see Watch transaction reports to the regulator.

Steps

Open a filing

Open “Reporting”, then Filings.

A strip above the table counts the “Pending approval” filings under Awaiting approval, the “Overdue” ones, and those that read “Anchor unconfirmed”. Select a figure to filter the table.

The table lists every attempt in the columns “Obligation”, “Regime”, “Report”, “Due”, “Status” and “Anchor”, followed by an unlabelled column of row actions. It filters by regime, report, filing state, anchor state, and whether the filing is overdue, and Search filings searches the rows.

Columns that do not fit the window are hidden, and “Due”, “Status” and “Anchor” move under the obligation name. View lists the hidden columns and turns any of them back on. Its count includes “Overdue”, which starts hidden, and leaves out the columns the window is too narrow for. Select a filing's name to open it in a sheet, which holds the lifecycle actions, the findings and the stored parts.

When the page opens, filings that need action come first, earliest due date first: “Ready for review”, “Pending approval”, and any attempt other than a superseded one whose period is overdue. Filings still in progress follow, earliest due date first, such as “Queued”, “Generation failed”, “Blocked”, “Approved” and “Submitted”. “Published”, “Acknowledged”, “Superseded”, “Rejected” and “Discarded” filings come last, latest due date first, unless their period is overdue. Ad-hoc filings and filings whose period could not be loaded have no due date, so each sits after the dated filings in its group. Select a column header to sort by that column instead.

If the page could not load the matching period, the row still appears and reads Filing period not loaded, the due date reads “No deadline on record”, and the regime and fiscal period stay empty.

A filing made with “Generate for date range” in Obligations shows the badge Ad hoc. Its fiscal period reads as the first and last day of the range, or as the one day for a single-day range. It has no deadline, so it is never overdue, raises no deadline alert and is never recorded as fulfilled late. Filing calendar lists scheduled periods only. An ad-hoc filing appears on Filings once its period is final and its files are generated, and then follows the same steps as any other filing.

Generate and request review

Select Generate on a queued attempt or to retry a failed generation. A filing that is “Ready for review”, “Pending approval” or “Approved” does not show “Generate”.

An “Approved” filing offers only its ending, “Record submission to authority” or “Publish”. To change it, replace it from the More menu, and the new attempt goes through review and approval again.

When the row reads “Ready for review”, select Submit for review.

Read the findings

A filing that is ready for review or waits for approval shows a Findings panel when validation raised findings.

A “Blocking” finding stays until you correct the data and generate the filing again. Select Replace under “More”, then “Generate” on the new attempt.

For a “Warning” finding, an organisation owner other than the maker selects Accept warnings, writes why the warnings are acceptable in “Why these warnings are acceptable”, and confirms. “Approve” stays unavailable until no finding stands, and the Console says “Accept the warnings to approve this filing.”

Approve the manifest digest

An organisation owner other than the maker opens Approve on a filing that is “Pending approval”. Check the “Manifest digest being approved” in the dialog, then confirm. The digest identifies the filing files being approved. If the filing changes while the dialog is open, the platform rejects the old approval. Close the dialog and review the updated filing before trying again.

Complete the filing

The obligation's published version determines how its filing is completed. A filing takes one of these two endings:

Fulfilment mode	Console actions
Authority acknowledgement	Send the filing through your organisation's channel, then select Record submission to authority. Someone other than the approver selects Record acknowledgement and enters the Authority receipt reference and the Authority acknowledgement time in local time.
Publication	An organisation owner selects Publish, checks the approved digest and enters the Publication reference.

Recording the authority receipt or publishing fulfils the filing period. The platform does not check the receipt with the authority: it records the reference and time you enter, and the period reads Fulfilled.

A receipt reference belongs to one submission, so the platform refuses a reference another submission carries. The Console marks the field and keeps the dialog open. Enter the reference the authority issued for this filing.

Return a filing to the maker

For a filing that is “Pending approval”, an organisation owner other than the maker can select Return to maker. The dialog is “Return filing to maker”. Explain what needs correcting in “Reason for returning the filing”. The reason is required and is recorded in the action log with your action. The filing returns to review. The maker cannot perform this checker action, and you must use your own session.

Replace, terminate, revive, waive or reject

More in the filing's sheet holds these acts. Each keeps the earlier attempt on record.

Replace supersedes an attempt that has not been sent with a new one of the “Replacement type” you choose: “New”, “Modification”, “Correction” or “Cancellation for error”.
Terminate supersedes it with a termination of the duty. A termination attempt offers “Revive” instead.
Record rejection records that the authority rejected a sent filing, with the “Reason the authority gave”. The filing becomes “Rejected”.
Waive period lets one organisation owner or platform administrator waive a period that has not opened, with a written reason in “Why this period is waived”. No second approver is asked, and the period reads “Waived” on Filing calendar.

Download or follow up on anchoring

Select Download to get one link for each stored artifact part. Each link is a pre-signed address that anyone who holds it can open for 15 minutes without signing in, so do not forward a link. Issuing the links is a sensitive read: the platform records it in the Audit trail when it can write the entry, and later use of a link is not recorded. The last part is filing.csv, which names the obligation version, filing period, organisation and reference window. The manifest digest covers it, so include it with the other parts when you verify an anchor in Anchor registry. Do not combine the parts: the anchored digest is computed across them, so a joined file does not match what was anchored.

Download stays disabled when no artifact exists, and the sheet says “No file has been generated for this attempt.” An erased filing shows a notice instead of links.

Select Anchor again to retry the anchor of a discharged filing whose anchor state is “Unconfirmed”.

Select Override exception to record why your organisation accepts that the filing is not anchored. The button in the dialog stays disabled until you enter a reason. The anchor state then reads “Accepted without anchor”, and the line under it reads “Accepted by” with your name and the date. When the person who accepted is not a member of the organisation, for example a platform administrator, the line reads “Accepted on” with the date only.

A filing with an anchor shows an Anchor registry entry link that opens that one entry in Anchor registry.

Place a legal hold

A legal hold keeps a filing, and the files behind it, while a matter such as a regulator's inquiry is live. It changes no filing state and withholds no download: it is the reason the files are still there, whatever the retention says.

The filing's sheet shows each open hold under “Legal hold” with its reason, when it was placed and who placed it. A filing with no open hold offers Place legal hold.

Open the filing from the table and select Place legal hold.
Write why this filing is held, in Why this filing is held. The reason is recorded in the Audit trail and shown to everyone who opens the filing.
Select Place legal hold. The filing's sheet shows the hold, and the retention sweep passes over the filing from then on.

Release a legal hold

A filing can carry more than one hold, and each is released on its own. Releasing the last open hold puts the filing back under its retention period.

Open the filing and select Release legal hold on the hold you mean.
Write why the hold is released, in Why the hold is released.
Select Release legal hold. The filing follows its retention period again: a period that already ended is erased by the next sweep, and one that has not ended yet ends later as usual.

Match the anchor state to the next step

Anchor state	What it means	What to do
Not requested	No anchor result is recorded for this filing. This is the default, and it stays after an anchor run is refused, for example because the filing is not discharged or anchoring is off.	If you expected an anchor, check the duty's anchoring setting in Obligations.
Still running	An anchoring attempt started and has not recorded a result.	Only a later anchoring attempt changes this state. The page offers no control while it lasts.
Confirmed	The filing's anchor landed, and no later attempt replaces it.	Use the row as evidence that the attempt has an anchor.
Unconfirmed	The anchor did not confirm after the last attempt, and the finding still stands.	On a discharged filing, an owner or platform administrator can select Anchor again. Either can select Override exception and record why, and the platform accepts one override for each filing.
Accepted without anchor	The anchor stayed unconfirmed and an owner or platform administrator overrode the exception with a recorded reason.	Nothing further. The filing stays unanchored, the override reason is on record, and the row says who accepted it and on which date.

Watch transaction reports to the regulator

Filings shows a Transaction reports to the regulator card below the filings table once the organisation has a published obligation that configures a regulator FIX session, a regulator session that has connected before, a queued trade report or an unmatched regulator answer. Anyone who can open Filings sees it. Trade reports explains what each report contains and how the session sends it.

Read Regulator connection. “Connected” with “Logged on” and a UTC time means the regulator accepted the session's Logon. “Disconnected” with “Reports wait until the connection returns” means a session is configured but is not logged on, so reports stay queued. “Not set up” means no published obligation configures a session. The platform keeps one record for each pair of sender and target CompIDs the organisation has used, so an organisation whose CompIDs changed shows one cell for each pair, named by the target CompID.
Read Waiting to be sent. The count is the queued reports, and “Oldest waiting” gives the age of the oldest one in minutes. The platform queues new trades every 15 seconds, and a connected session sends up to 100 queued reports at a time.
Read Unmatched regulator answers. Each row is an answer that moved no report, with the time “Received”, the “Report” it named, or “No report named”, and the “Reason”. The platform keeps every row. The panel shows the newest 50 by the time they were received.

The session works when the connection reads Connected, “Waiting to be sent” reads 0, and no new row appears under “Unmatched regulator answers”.

What you see	What to do
Disconnected and a growing Waiting to be sent count	The session did not start or is not logged on. Ask the platform operator whether the regulator endpoint is on the deployment's allow list, whether the session's schedule window is open, and whether the session is held after a fault, which keeps it down until its configuration changes. Check on Obligations that only one published trade journal version configures a session and that its message layout names a FIX version the session supports. If the regulator cannot be reached, file the trade journal export through your own channel as Trade reports describes.
Not set up and a growing Waiting to be sent count	The trade journal is in a published obligation that configures no regulator session, so its reports are queued and never sent. File the trade journal as a file, or publish a version that configures a session.
Not set up on a duty that should send trade reports	Check on Obligations that a version with a regulator session is published.
“The regulator sent a message that is not an answer to a transaction report”	Compare the message with the regulator's specification, and ask the regulator what the message was meant to answer. No report changed.
“The answer lacks a field needed to read it”	Check that the message layout's answer settings match the regulator's acknowledgement format. Publish a corrected version if they differ.
“The answer names a report that was never queued” or “The answer does not fit the report's current state”	Compare the answer with the regulator's records. Find the report's `id` with `GET /api/v2/reporting/transaction-reports?filter[q]=` and the report ID the answer named. An organisation owner or a platform administrator sets the report's state with `POST /api/v2/reporting/transaction-reports/{transactionReportId}/transitions`. The platform takes that person's word for the regulator's answer, asks no second approver and records the change in the audit trail.
“The regulator rejected a session message that carried no report”	Ask the regulator why it rejected the message. No report changed.

Watch the regulator reporting evidence

Below the transaction reports card, Filings shows a Regulator reporting evidence card for the last 24 hours. It appears when the period has session history, messages, reports, delay breaches or alerts, or when a reconciliation, legal hold or certification run exists. It is read-only. Placing a hold and recording a certification run use the Platform API, as Trade reports describes.

Read the strip. Session uptime is the share of the period that the regulator had accepted a Logon, and shows the lowest figure when the organisation has more than one session. “Logons” and “Logouts” count the session's logon and logout events. “Session rejects” counts messages the regulator refused at session level. “Waiting to be sent” is the queue, with “Oldest waiting” in minutes. “Reports sent late” counts reports that waited longer than 15 minutes, until they were sent or the period ended.
Read Daily reconciliation. Each row is one version of one “Trading day”, with “Trades and busts” executed, how many are “Acknowledged”, and “Breaks”. “Balanced” means every trade and bust was acknowledged. A number means that many have no acknowledged report, and the day has an open operations case that closes when a later version balances.
Read Alert history for the days that raised a break alert, “Logon and logout history” for each event with its “Reason”, “Legal holds” with each hold's “Reason”, when it was “Placed” and whether it is “Active” or “Released”, and “Certification runs” with each run's “Environment”, “Outcome” and “Cases passed”.

A table with no rows is left out. The lines behind a reconciliation, the session's messages and the exports are available through the Platform API and as reports of kind regulator-reconciliation, regulator-messages and regulator-monitoring.

How long a filing is kept

A filing keeps its stored files for the retention its obligation sets under Keep for. “Five years”, “Seven years” and “Ten years” count from the day the filing is accepted, and “Indefinitely” never erases. When the retention ends, the platform erases the stored files and keeps a record of the erasure: the manifest digest, the retention it was kept under and the number of objects removed. Download any filing you must keep longer before its retention ends.

The filing's sheet shows The stored file has been erased, “Retained under” with the retention, and how many objects are confirmed gone. “Download” offers no links. While the platform is still writing the erasure record, the sheet reads “The erasure is still being recorded, so no tombstone is available yet.”

Where the deployment stores reports on write-once storage, nobody can replace or delete a filing's files until the lock ends. See Values and secrets.

A legal hold on a filing stops the erasure whatever its retention says. Place a legal hold and Release a legal hold say how to hold one filing and how to release it again. Once the last open hold is released, the platform erases the files if the retention has already ended.

Who can do what

Opening the screen and acting on it need different roles. Any role listed for this page opens the screen. The controls follow the person's organisation role. A platform administrator holds the deployment's platform role and gets these controls in every organisation they are a member of, whatever their organisation role:

Control	Who is offered it
Generate, Submit for review, Record submission to authority, Replace, Terminate, Revive, Record rejection	An organisation owner, an organisation member or a platform administrator.
Record acknowledgement	The same people, other than the person who approved the filing, and not from an impersonated session.
Approve, Accept warnings, Return to maker	An organisation owner other than the maker, not from an impersonated session.
Publish	An organisation owner, not from an impersonated session.
Waive period	An organisation owner or platform administrator, not from an impersonated session.
Download, Anchor again	An organisation owner or a platform administrator.
Place legal hold, Release legal hold	An organisation owner or a platform administrator, not from an impersonated session.
Override exception	An organisation owner or a platform administrator, not from an impersonated session.

A reader who is neither an organisation owner nor a platform administrator sees the note “Organisation owners approve and publish filings. Organisation owners and platform administrators download them.”

Get email about a filing

The platform emails the organisation's owners who have an email address on file. Each email names the filing and has one button that opens it. No email carries the filing's files or rows.

Email	When it is sent	Who is left out
Filing ready for review	The filing is generated and waits for review.	The person who started the generation.
Filing could not be generated	Generation failed. Open the filing in the Console to see why, then start it again.	Nobody.
Filing not acknowledged in time	The authority has not acknowledged the filing within its acknowledgement window.	Nobody.
Filing deadline approaching	The filing has not been submitted and its deadline is close. The email shows the deadline in the organisation's time zone.	Nobody.
Filing deadline passed	The deadline passed without a submission.	Nobody.

The platform sends each acknowledgement and deadline email once per alert. Without a configured mail transport it sends no email, so check the Console.

Troubleshooting

What you see	What it means and what to do
No filings yet	No filing period in this organisation has produced an attempt. Check Filing calendar for generated periods and Obligations for whether the duty has a published version.
Deadlines unavailable, or a duty name or deadline is missing	The filing periods could not be loaded. The page still lists the filing attempt and shows the notice. Refresh the page to try again.
Download is unavailable	A stored artifact must exist, and your account must be an organisation owner or platform administrator. Ask one of those users to download it, or read the filing state and anchor state.
An anchoring action was refused	Only an organisation owner or a platform administrator sees these controls, and the platform refuses the request from anyone else. An impersonated session cannot override an anchor exception.
Anchor again is unavailable	The Console offers Anchor again only on a discharged filing, one that is Acknowledged or Published, whose anchor state is Unconfirmed. Before discharge, an Approved filing can still be replaced, which starts a fresh attempt.
That action was refused	The Console shows the platform's reason. When the filing has moved on, the dialog says “This filing has moved on, so this action no longer applies.” Close the dialog and read where the filing stands.

API routes

The screen uses these reporting routes of the Platform API:

GET /api/v2/reporting/submissions lists filing attempts, and POST /api/v2/reporting/submissions/{submissionId}/generations starts a generation.
POST /api/v2/reporting/submissions/{submissionId}/acts carries the lifecycle acts: submit for review, approve, record submission, acknowledge, publish, replace, terminate, revive, waive and reject.
GET /api/v2/reporting/submissions/{submissionId}/artifact returns the download links.
POST /api/v2/reporting/submissions/{submissionId}/anchoring/transitions retries an anchor and answers confirmed without starting a run when the filing is already anchored, and POST /api/v2/reporting/submissions/{submissionId}/anchor-overrides records an override.
GET /api/v2/reporting/transaction-reports and POST /api/v2/reporting/transaction-reports/{transactionReportId}/transitions read and correct transaction reports.