# Compliance and reporting

Source: https://docs.settlemint.com/docs/changelog/dalp-3-2/compliance-and-reporting
Filings generated from the ledger and approved by a second person, anchored digests, a hash-chained audit trail, client statements and second approvers.

**Your team produces each filing from the ledger it already runs, and can show a regulator who prepared it, who approved it and, once anchoring is on, that the file is the one approved.** Deadlines arrive in several formats, and the question a supervisor asks afterwards is what was filed and who signed it off. Each filing is generated from an obligation you publish, approved by someone other than its maker, and kept with every step on the record.

Spotlight: Filings, statements and audit entries come from the ledger and name who acted

- Report families: 41, from holder register to venue pack
- Filing sign-off: A second person, never the maker. A waiver takes one.
- Audit trail: Hash chain, anchored daily once set up
- Filing to the regulator: Your team, recorded in DALP

The platform generates each filing, records its review, approval and the authority's answer, and keeps the files for the retention class the obligation sets. Your team files it through the authority's own channel.

## Before and after [#before-and-after]

**Before 3.2:** A compliance team rebuilds each filing from register exports and spreadsheets, collects sign-off by email, and answers a regulator's question about who changed what by stitching together service logs. Nothing ties the file a regulator received to the one that was approved.

**With 3.2:** you publish each duty as an obligation, and the platform builds the calendar and generates every filing from the ledger once its period is final. A second person approves the filing's digest, the digest can go on chain for anyone to check, and each state-changing request to the Platform API leaves an audit entry in a hash chain whose daily head can be anchored on chain.

[Figure] A filing is generated from the ledger, approved by a second person and can be checked against the chain. A published obligation version sets the cadence, deadline and file layout. When a period ends and the chain is final, the platform generates the filing from the ledger's report families. A maker submits it for review with its validation findings, and a second organisation owner or organisation administrator approves its digest. The organisation's team files it through its own channel and records the submission, then records the authority's receipt with its reference. When anchoring is on, the filing's digest is written to the chain, and anyone holding the file can check it. Every step leaves an audit trail entry in a hash chain whose daily head is anchored once anchoring is set up. Labels: Published version; Obligation; Cadence, deadline, layout; Generated from ledger; Period ends; Named report families; Submit for review; Maker; Validation findings shown; Approves the digest; Second person; Org owner,; not maker; Your team files it; Your channel; Submission recorded; Receipt recorded; Authority; Reference and time; Digest written on chain; When anchoring is on; Anyone holding the file can check it against the registry; Every step; In the audit trail, a hash; chain anchored once set up.

A published obligation drives a filing from generation through a second person's approval to the authority's receipt, with every step in the audit trail.

## Generate each filing from the ledger and prove who approved it [#generate-each-filing-from-the-ledger-and-prove-who-approved-it]

You publish the obligations your regulators set, and the filing calendar follows them. A published obligation version sets the cadence, the deadline, the holiday calendar and the file layout. Each organisation starts with the platform's obligation catalogue as unpublished drafts, including the ADGM information-rights disclosures and a quarterly distribution report. Filings draw on 46 report families, among them the holder register, custody positions, the client asset summary, the safeguarding extract, dormant accounts, settlement and fails, corporate action entitlements and payments, redemptions, the distribution waterfall, privileged actions, security incidents, wallet changes and the end-of-day venue pack generated at each market close. A filing comes out as CSV, XLSX, ZIP, JSON, XML or PDF, with an authority file in the layout the obligation defines.

![Filings page with counts of filings awaiting approval, overdue and with an unconfirmed anchor, above a table of filings](https://docs.settlemint.com/docs/screenshots/console-reporting-filings-list.light.en.webp)

[Screenshot] Your reporting team sees every filing, what awaits approval and what is overdue.

A quarter ends, and once the chain is final past it the platform generates the filing and checks it against the obligation's validation rules. The Reporting officer opens it on "Filings", reads the findings and selects **Submit for review**, which makes them the maker. An Organisation owner sees the filing waiting in the Actions inbox, opens the approval dialog, which shows the filing's manifest digest, and selects "Approve". The team uploads the file to the authority's portal, and a member selects "Record submission to authority" and later "Record acknowledgement" with the authority's reference and time. The person who approved the filing cannot record its receipt. Whatever the approval policy says, a filing is approved by an organisation owner or organisation administrator other than the person who submitted it, and a platform administrator who holds neither organisation role cannot approve it.

When a supervisor asks who approved last quarter's filing, the answer is on the filing: the maker, the approver, the digest they approved and the receipt. A blocking finding stops the approval until the data is corrected, and a correction goes through a new attempt that keeps the earlier one. An organisation owner or platform administrator can still waive a period alone with **Waive period** and a written rationale, which stays on the record, so a waived period has no second person. DALP generates and tracks filings but does not upload them to a regulator's portal, so a person files each one and records the submission. An obligation fulfilled by publication records the publication instead.

A filing can also be held. An organisation owner or platform administrator opens a filing and selects **Place legal hold** with the reason, and the filing and its files stay whatever the obligation's retention class says until the hold is released. A regulator's inquiry is the usual reason: the hold records who placed it and when, and it appears on the filing with a "Release legal hold" button beside it. Until 3.2 the Console showed a hold on a filing that nothing could place.

## Let a regulator or auditor check a filing against the chain [#let-a-regulator-or-auditor-check-a-filing-against-the-chain]

An organisation owner or platform administrator can anchor each fulfilled filing of an obligation, and any investor report, as a digest in an append-only registry on the organisation's on-chain system, on the network they select. The registry holds the digest, never the file. Whoever holds the document can later check that it is the exact one the issuer committed to, without sending it anywhere.

An Organisation owner turns on **Anchor filings on chain** for the quarterly obligation, with a label, a written reason and a confirmation that the entry is permanent and public. A label that names the organisation, a period or an id-like value asks the person to confirm that it becomes public and permanent before it is stored. When the next filing is acknowledged, the platform writes its digest, and the filing links to its "Anchor registry" entry. An auditor with a Console account who received the PDF opens "Check a document", names the issuer and picks the file. The browser hashes it, and the answer says the issuer anchored exactly those bytes. Holders get the same check on an asset's Documents tab in the Console and the Investor portal.

The registry only appends, so a later entry cannot change an earlier one, and the check needs no Reporting access, so a holder can verify a notice they received. A failed anchor raises a finding and never changes the filing, so a chain outage does not make an organisation miss a deadline. Anchoring stays off until an organisation owner or platform administrator turns it on for an obligation, and it needs a document anchor registry on the organisation's on-chain system.

## Prepare FSRA venue reports and send trade reports over FIX [#prepare-fsra-venue-reports-and-send-trade-reports-over-fix]

A trading venue in the Abu Dhabi Global Market answers to the Financial Services Regulatory Authority, the FSRA. The two obligations below serve a venue there, and a venue under another regulator publishes its own obligations and file layouts. Two catalogue obligations produce the FSMR s.149 transaction and order report files as daily CSVs, each filing ending with the authority's acknowledgement. The FSRA has published no rules on what these reports hold or when they are due, so the layout, modelled on MiFIR RTS 22 and RTS 24, the daily cadence and the deadline of 23:59 Asia/Dubai on the next ADGM business day are DALP's provisional reading, and the obligations carry no validation rules. For a regulator that takes trade reports over FIX, the Financial Information eXchange protocol, a published trade journal obligation can name a FIX session, and the platform keeps that session open from inside the deployment and sends the reports itself.

A trade matches on the venue, and on its next pass the platform queues a trade report under the obligation's frozen message layout. The regulator session sends queued reports oldest first, and a regulator acceptance with its reference marks the report acknowledged. A rejection keeps the regulator's reason, and an Organisation owner corrects the report, which is rendered again from the same obligation version and sent under the same report ID. While the session is down, the trade journal downloads as a file, and the owner files it by hand and records each outcome.

Every executed trade and every bust leaves a durable report with its body, its answer and its correction history, even when the regulator's line is down. Replace the seeded submitting-entity LEI and venue code with your own before you publish the FSRA obligations.

The platform also proves that the reports reached the regulator. A daily reconciliation compares each trade and bust of a closed trading day with the report the regulator acknowledged, keeps every result as a numbered version, and raises an operations case and an alert when a day has breaks. The platform records every message of the regulator session, administrative messages included, under a retention class you set, with legal holds and a date-range export. Filings shows the session's uptime, logon history, delays and alerts for the last 24 hours, and exports the same evidence as a report. A certification script runs the new report, bust, reject and resend, and reconnect cases against a local acceptor or the regulator's test environment, and records the run with the obligation version. The FSRA's specification, test endpoint and retention period are not part of the platform: you supply them as configuration when the FSRA publishes them, and a run against the local acceptor is not a certification.

## Show the person, the role and the change behind every request [#show-the-person-the-role-and-the-change-behind-every-request]

A chain signature names only the key that signed, and says nothing of the person who clicked, their role, or a request refused before it reached the chain. The audit trail records each state-changing request to the Platform API and each read of sensitive data, with the person, their organisation role at the time, how they signed in, the participant they acted for, the operation and the outcome. When an administrator acts as another user, the entry names both. Where the operation supplies them, changes record their before and after values with secrets redacted, and maker-checker decisions name the maker and the checker.

An Organisation owner changes the withdrawal fee schedule for one asset and gives the reason "Q4 tariff". The Reporting officer opens **Audit trail** under Reporting, filters on the action and opens the entry. It names the owner, the role "Owner", the sign-in method and the reason, and shows the old and new fee. The officer then selects "Export" for the quarter and gets a CSV of every matching entry, and that export writes its own entry naming who took it.

Each organisation's trail is a SHA-256 hash chain. Once anchoring is set up for the organisation on its default network, a daily sweep anchors each closed day's chain head on chain, and until then the sweep logs the gap and tries again. An integrity read through the Platform API reports the chain intact, or names the first row that differs. Entries are kept indefinitely by default, and a deployment can set 5, 7 or 10 years, after which a day is deleted only once it is anchored, held by no legal hold and archived in an end-of-day audit report. A change the platform cannot record is refused, and so is an export. Other sensitive reads are still served and the failure is logged, and sign-in and other account events go through even when their entry cannot be written.

## Send clients statements, contract notes and trade confirmations [#send-clients-statements-contract-notes-and-trade-confirmations]

An Organisation owner sets the statement policy on **Statements**: daily, weekly, monthly or quarterly, with the sections and formats clients get. A new organisation sends monthly statements with every section in CSV and PDF. Statements cover positions, the portfolio at close, movements, profit and loss, fees, custody deposits and withdrawals, and corporate actions, and the PDF carries the organisation's theme.

An investor trades on the venue during the day. After the session closes, the platform writes a contract note with each trade, its fee, VAT and net amount, and emails it with the files attached. A later bust replaces the note with an Amended edition. At month end the investor's statement arrives the same way, and Activity offers a CSV or XLSX confirmation for each final movement on their wallets. A partner system subscribed to the statement-ready webhook learns about each statement without polling.

A holder sees only their own wallets. A position without a price shows as unpriced and is left out of the statement's total, and the total says how many it left out.

## Keep approvals and conflicting roles in separate hands [#keep-approvals-and-conflicting-roles-in-separate-hands]

An organisation owner or platform administrator picks, in one place, which of ten families of change wait for a second approver: offerings, corporate actions, trading venues, reporting, bank rail, custody operations, withdrawals, prices, wallets and administration. A family can ask for up to ten distinct approvers. On an instance SettleMint operates, a platform administrator may be SettleMint staff. Turning a family off asks for that person's wallet verification, and while administration changes are protected, another owner approves the turn-off first. The same people name pairs of roles one wallet may not hold together, such as custodian and governance on the same token, and set each pair to block, or to warn, where a conflicting grant needs a reason the audit trail keeps. Time-bound token roles and organisation ownership end on their own at their expiry.

An Organisation owner opens "Approvals" under General and turns on **Corporate actions**, which then reads "Second person required". From then on, recording a corporate action waits for a second person, and a request raised while a family is off shows "No second approval (approval off)" in Actions, never "Approved". Once the owner has saved the role-pair rules, a grant of the Governance role to the wallet that holds Custodian on the same bond is refused with "Custodian cannot be held with Governance on the same contract" before anything reaches the chain.

A report lists every wallet that holds a segregated pair, including roles granted on chain outside the platform, so an auditor sees which controls the organisation runs. Every approval family starts off, and the role-pair rules stay off until an organisation owner or platform administrator saves them.

## Check a transfer against the asset's rules before anyone signs [#check-a-transfer-against-the-assets-rules-before-anyone-signs]

Transfer pre-check answers, before anyone signs, whether a transfer would clear the asset's compliance rules. When it would not, it names each blocker it can establish and who can resolve it: the party, an operator, or nobody without changing the transfer. An investor verification can carry a date after which it no longer holds, so a claim expires when the document behind it does.

An investor fills in a transfer in the Investor portal, and before signing the sheet says that the recipient lacks a verification the asset's rules require, a blocker an operator can resolve. Nothing reaches the chain, and nobody pays gas for a transfer that would revert. A holder could delete a claim from their own identity, so a rule that excludes holders by such a claim is refused for topics such as KYC, AML and sanctions screening, and needs an explicit acknowledgement for topics such as accreditation. Sanctions screening runs through block lists the issuer controls.

A clear result reserves nothing, and the real transfer can still fail. A wallet that a compliance manager, or one of DALP's own factories, puts on the compliance bypass list skips these transfer checks, so review that list alongside the rules. A custodian's forced transfer skips them by design.

## Hold a frozen address on chain, not only in the Console [#hold-a-frozen-address-on-chain-not-only-in-the-console]

A custodian freezes a wallet on a DALP asset while a review runs. The chain now refuses a forced transfer that would deliver units into that wallet, as it already refused a mint or a transfer to it, and refuses a supply manager's burn from it. To take the units, the custodian forced-transfers them out of the frozen wallet, which a freeze still allows, or lifts the freeze. A partial freeze keeps its earlier rule: a supply manager's burn or a forced transfer draws down the frozen units it needs.

A halt on an asset that is already halted now fails with [DALP-1109](https://docs.settlemint.com/docs/api-reference/errors), the code for a halted token, and a resume on an active asset fails with [DALP-9059](https://docs.settlemint.com/docs/api-reference/errors). The Console shows "is already halted" or "is already active" for either code. An asset on an earlier token implementation, including a legacy asset type, keeps the earlier behaviour.

## Upgrading [#upgrading]

The audit trail, the approval policy and the transfer pre-check are on after the upgrade. Every approval family starts off, so an organisation owner or platform administrator turns on the ones the organisation needs, and the role-pair rules stay off until one of them saves them. Audit entries are kept indefinitely unless the operator sets a retention period. Filings, anchoring, statements and trade reports run only once the operator, whoever runs your deployment, switches regulatory reporting on for the deployment, and trade reports also need the trading venue switched on. A regulator FIX session runs only to endpoints the operator allows for the deployment. Catalogue obligations arrive as drafts, so nothing is filed until you publish one. [Decide which capabilities your deployment runs](https://docs.settlemint.com/docs/deployment/upgrade-to-3-2#decide-which-application-layers-to-switch-on).

## Why it matters [#why-it-matters]

- **Banks:** an organisation owner other than the maker approves each filing's digest, and the authority's receipt stays on the filing.
- **Exchanges, CSDs and market infrastructures:** the end-of-day venue pack, the FSRA report files and FIX trade reports to a regulator come from the same trades the venue settled.
- **Regulators:** each filing names its maker and its approver, its digest can be checked on chain once anchoring is on, and the trail shows who acted in which role.
- **Partners:** A webhook announces each client statement, so a partner's app reports to its own clients without polling.

## Next steps [#next-steps]

- [Work filings in the Console →](https://docs.settlemint.com/docs/console/reporting/filings)
- [Read the audit trail →](https://docs.settlemint.com/docs/console/reporting/audit-trail)
- [Understand reporting obligations →](https://docs.settlemint.com/docs/concepts/records-and-evidence/reporting-obligation)