Regime packs · one proof, mapped to each rule
What to record, rule by rule
The evidence log proves that a record existed, unaltered, no later than a signed and anchored head. It does not know what the record is. A pack says, for one regime, which fields to put in a record so that the proof answers the question a supervisor will ask, and maps each field to the article it speaks to. The record stays with you; only its salted fingerprint is sent. Five packs are published, as data anyone can use without us.
How it works
A record, its fingerprint, and the bundle you hand over
- 1. Write the record
- A JSON object with the pack's fields, in your own system. Identify people and cases by your own references, never by name: the pack's reference fields refuse anything that looks like a name or an email.
- 2. Send its fingerprint
- Canonicalise it (RFC 8785, with the profile in the specification), hash it with a random salt, and send only the digest and the kind to
POST /api/v2/evidence. Optionally sign it with your own key, so the leaf carries your signature too. - 3. Keep three things
- The record, the salt, and the proof the API gives for the entry. Together they are a bundle:
riskrouter-record-bundle|1. - 4. Hand over the bundle
- Anyone can check it offline with either verifier: the record hashes to the recorded digest, its kind is the recorded kind, the entry is in a tree whose head we signed, and, for a signed leaf, your own signature holds.
# validate a record against its pack, then fingerprint it
node records.mjs validate statement.json
node records.mjs digest statement.json # prints salt_hex and record_digest; keep both
# after recording: bundle it with the proof, and check it the way a supervisor would
node records.mjs bundle statement.json --salt $SALT --proof proof.json > bundle.json
node records.mjs check bundle.json --key signing-key.json
python3 riskrouter_verify.py bundle.json --key signing-key.json
records.mjs ships with the conformance suite, beside the packs,
and in the public verifier repository;
the Python verifier is in the kit. The Python client's
record_structured() does steps 2 and 3 for you.
What the log proves
What a bundle shows, and what it cannot
- It shows
- That this exact record, with these field values, existed no later than the head's time and the Bitcoin block its anchor is in, and has not been changed since. With a signed leaf, that you asserted it. A correction is a new record naming the old one in
supersedes, and the old one stays: what was there before a correction can always be seen. - It does not show
- That the record is true or complete, that an obligation applied to you, or that you met it. Whether a regime applies, what it requires of you, and how long to keep records are for you and your supervisor.
- Where the log adds most
- Where a rule asks that records cannot be altered or that logs are kept: Delegated Regulation (EU) 2017/565, Article 72(1), and the AI Act's Articles 12, 19 and 26(6). A database row can be edited by whoever administers it; a fingerprint in an anchored tree cannot be changed without the change showing.
EU AI Act · pack ai-act version 1
High-risk AI systems: logs, decisions and human oversight
What a provider or deployer of a high-risk AI system records so that its logs, the decisions taken on the system's output, and the human oversight exercised over it can be shown later to be exactly what existed at the time.
- The law
- Regulation (EU) 2024/1689 (Artificial Intelligence Act) (CELEX 32024R1689)
- Kinds
ai.log-segmentlog segment sealedai.decisiondecision taken on the system's outputai.oversighthuman oversight exercised- The file
- /packs/ai-act.json, with an example record for every kind
- How long to keep it
- Articles 19(1) and 26(6) set a minimum of six months for the logs they cover, unless other law provides otherwise; this pack does not decide your period. Whether your system is high-risk, and from when these obligations apply to it, is yours to establish from the Regulation.
What each article asks, in our words, and where a record answers it
| Article | What it asks (our summary; the linked text is the law) | Recorded in |
|---|---|---|
| Regulation, Article 12(1) | High-risk AI systems must technically allow for the automatic recording of events (logs) over the lifetime of the system. | ai.log-segment: system_ref, segment_start, segment_end, event_count, log_digest, previous_segment_record_id |
| Regulation, Article 12(2) | Logging must enable recording of events relevant for identifying situations that may result in the system presenting a risk or in a substantial modification, for post-market monitoring (Article 72), and for monitoring the system's operation (Article 26(5)). | ai.log-segment: system_versionai.decision: system_ref, system_version, input_digest, output_digest, decided_at |
| Regulation, Article 14(4)(d) | The people overseeing the system must be able to decide, in any particular situation, not to use it or to disregard, override or reverse its output. | ai.decision: human_involvedai.oversight: system_ref, decision_record_id, overseer_ref, action, reason, acted_at |
| Regulation, Article 19(1) | Providers keep the logs their high-risk AI systems generate automatically, to the extent the logs are under their control, for a period appropriate to the system's intended purpose and of at least six months, unless Union or national law, in particular on personal data, provides otherwise. | ai.log-segment: role, log_digest, retain_until |
| Regulation, Article 19(2) | Providers that are financial institutions subject to internal-governance requirements under Union financial services law keep those logs as part of the documentation kept under that law. | ai.log-segment: retain_until |
| Regulation, Article 26(6) | Deployers keep the logs the system generates automatically, to the extent the logs are under their control, for a period appropriate to the system's intended purpose and of at least six months, unless applicable law provides otherwise. | ai.log-segment: role, log_digest, retain_until |
| Regulation, Article 86(1) | A person affected by a decision a deployer takes on the basis of output from a high-risk AI system listed in Annex III (other than point 2), with legal or similarly significant adverse effects, may obtain clear and meaningful explanations of the role of the AI system in the decision and of the main elements of the decision taken. | ai.decision: system_ref, case_ref, output_summary, role_of_system, decision |
ai.log-segment · Log segment sealed
When: Each time a segment of the system's automatic log is closed: every hour, every day, or every file rotation.
| Field | What to put in it | Type | Mapped to |
|---|---|---|---|
system_ref | Your reference for the AI system. | your reference | Article 12(1) |
system_version | The version of the system that produced the log. | one line | Article 12(2) |
role | Whether you keep this log as the provider or as a deployer. | one of provider, deployer | Article 19(1) Article 26(6) |
segment_start | Time of the first event in the segment, UTC. | UTC time | Article 12(1) |
segment_end | Time of the last event in the segment, UTC. | UTC time | Article 12(1) |
event_count | How many events the segment holds, so a shortened log is caught. | whole number | Article 12(1) |
log_digest | SHA-256 of the segment file exactly as stored. | SHA-256 | Article 12(1) Article 19(1) Article 26(6) |
log_format (optional) | The format of the segment, such as jsonl. | one line | – |
previous_segment_record_id (optional) | The record_id of the segment before this one, so a missing segment is caught. | your reference | Article 12(1) |
retain_until (optional) | The date until which you have decided to keep this segment. | date | Article 19(1) Article 26(6) Article 19(2) |
ai.decision · Decision taken on the system's output
When: When a decision about a person or a case is taken on the basis of the system's output.
| Field | What to put in it | Type | Mapped to |
|---|---|---|---|
system_ref | Your reference for the AI system. | your reference | Article 12(2) Article 86(1) |
system_version | The version of the system that produced the output. | one line | Article 12(2) |
case_ref | Your reference for the case or the person concerned. Never a name. | your reference | Article 86(1) |
input_digest (optional) | SHA-256 of the input exactly as the system received it. | SHA-256 | Article 12(2) |
output_digest (optional) | SHA-256 of the output exactly as the system produced it. | SHA-256 | Article 12(2) |
output_summary | What the system output, in words someone can check against the output. | text | Article 86(1) |
role_of_system | The role the system's output played in the decision. | text | Article 86(1) |
decision | The decision taken, and its main elements. | text | Article 86(1) |
human_involved | Whether a person reviewed the output before the decision. | true or false | Article 14(4)(d) |
decided_at | When the decision was taken, UTC. | UTC time | Article 12(2) |
ai.oversight · Human oversight exercised
When: When a person overseeing the system confirms, overrides, reverses or declines to use its output, or stops it.
| Field | What to put in it | Type | Mapped to |
|---|---|---|---|
system_ref | Your reference for the AI system. | your reference | Article 14(4)(d) |
decision_record_id (optional) | The record_id of the ai.decision record concerned, if any. | your reference | Article 14(4)(d) |
overseer_ref | Your reference for the person who acted. Never a name. | your reference | Article 14(4)(d) |
action | What the person did with the output. | one of confirmed, overridden, reversed, not-used, stopped | Article 14(4)(d) |
reason | Why. | text | Article 14(4)(d) |
acted_at | When, UTC. | UTC time | Article 14(4)(d) |
The log itself never leaves you: only the digest of each segment is recorded. A segment produced later can then be shown to be the segment that existed when it was sealed, and event_count and previous_segment_record_id make a shortened or missing segment visible.
DORA · pack dora version 1
ICT incidents, incident reports and the register of information
What a financial entity records so that its incident log, the reports it sent to its competent authority and its register of ICT third-party arrangements can be shown later to be exactly what existed at each date.
- The law
- Regulation (EU) 2022/2554 (Digital Operational Resilience Act) (CELEX 32022R2554)
- Kinds
dora.incidentincident recorded at a stagedora.incident-reportreport submitted to the competent authoritydora.register-snapshotregister of information at a date- The file
- /packs/dora.json, with an example record for every kind
- How long to keep it
- This pack does not state how long to keep these records. Check the period with your competent authority.
What each article asks, in our words, and where a record answers it
| Article | What it asks (our summary; the linked text is the law) | Recorded in |
|---|---|---|
| Regulation, Article 17(1) | Define, establish and implement an ICT-related incident management process to detect, manage and notify ICT-related incidents. | dora.incident: stage, detected_at, stage_at |
| Regulation, Article 17(2) | Record all ICT-related incidents and significant cyber threats, with procedures for consistent monitoring, handling and follow-up so root causes are identified, documented and addressed. | dora.incident: incident_ref, category, description, root_cause, actions |
| Regulation, Article 18 | Classify ICT-related incidents and determine their impact against the criteria the article sets. | dora.incident: classification, services_affected |
| Regulation, Article 19(4) | For a major ICT-related incident, submit to the competent authority an initial notification, an intermediate report and a final report. | dora.incident-report: incident_ref, report_type, authority, report_digest, submission_ref, submitted_at |
| Regulation, Article 28(3) | Maintain and update a register of information on all contractual arrangements for ICT services provided by ICT third-party service providers. | dora.register-snapshot: as_of, register_digest, arrangements, purpose |
dora.incident · Incident recorded at a stage
When: At each stage of an ICT-related incident or significant cyber threat: detected, classified, resolved, closed.
| Field | What to put in it | Type | Mapped to |
|---|---|---|---|
incident_ref | Your reference for the incident. | your reference | Article 17(2) |
stage | The stage this record captures. | one of detected, classified, resolved, closed | Article 17(1) |
category | Whether it is an incident or a significant cyber threat. | one of ict-related-incident, significant-cyber-threat | Article 17(2) |
classification | Your classification under Article 18 at this stage. | one of major, not-major, not-yet-classified | Article 18 |
services_affected (optional) | Your references for the services affected. | list of your reference | Article 18 |
description | What happened, as known at this stage. | text | Article 17(2) |
root_cause (optional) | The root cause, once identified. | text | Article 17(2) |
actions (optional) | What was done, and what will be done to prevent recurrence. | text | Article 17(2) |
detected_at | When the incident was detected, UTC. | UTC time | Article 17(1) |
stage_at | When this stage was reached, UTC. | UTC time | Article 17(1) |
dora.incident-report · Report submitted to the competent authority
When: When an initial notification, an intermediate report or a final report is submitted.
| Field | What to put in it | Type | Mapped to |
|---|---|---|---|
incident_ref | Your reference for the incident. | your reference | Article 19(4) |
report_type | Which report. | one of initial-notification, intermediate-report, final-report | Article 19(4) |
authority | The competent authority it went to. | one line | Article 19(4) |
report_digest | SHA-256 of the report exactly as submitted. | SHA-256 | Article 19(4) |
submission_ref (optional) | The authority's acknowledgement reference, if any. | your reference | Article 19(4) |
submitted_at | When it was submitted, UTC. | UTC time | Article 19(4) |
dora.register-snapshot · Register of information at a date
When: Each time the register is updated, and when it is submitted.
| Field | What to put in it | Type | Mapped to |
|---|---|---|---|
as_of | The date the register describes. | date | Article 28(3) |
register_digest | SHA-256 of the register file exactly as kept or submitted. | SHA-256 | Article 28(3) |
arrangements | How many contractual arrangements it lists. | whole number | Article 28(3) |
file_format (optional) | The format of the file, as your authority names it. | one line | – |
purpose | Whether this is an internal update or the version submitted. | one of update, submission | Article 28(3) |
The reports themselves go to your authority by its own channel; the log never sends anything to anyone. What the log adds is that the report you hold today can be shown to be the one you held on the day you submitted it.
GDPR Article 22 · pack gdpr-art22 version 1
Automated individual decisions: basis, information and human intervention
What a controller records to show, for a decision based solely on automated processing, which exception it relied on, what the person was told, and what happened when they asked for a human to look again.
- The law
- Regulation (EU) 2016/679 (General Data Protection Regulation) (CELEX 32016R0679)
- Kinds
gdpr.automated-decisionautomated decision takengdpr.human-interventionhuman intervention requested and handled- The file
- /packs/gdpr-art22.json, with an example record for every kind
- How long to keep it
- This pack does not state how long to keep these records. The records are yours and hold personal data under your control: keep them no longer than your purposes need, and they stay erasable because they never leave you. Only a salted digest is in the log, and without the record and its salt nobody, including us, can link it to anyone.
What each article asks, in our words, and where a record answers it
| Article | What it asks (our summary; the linked text is the law) | Recorded in |
|---|---|---|
| Regulation, Article 5(2) | The controller is responsible for, and must be able to demonstrate, compliance with the principles in Article 5(1). | gdpr.automated-decision: basis_ref, outcome, decided_atgdpr.human-intervention: reasons |
| Regulation, Article 13(2)(f) and Article 14(2)(g) | Inform the person of the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4), and at least in those cases give meaningful information about the logic involved and the significance and envisaged consequences. | gdpr.automated-decision: information_digest |
| Regulation, Article 22(1) | A person has the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning them or similarly significantly affects them. | gdpr.automated-decision: subject_ref, decision_ref, solely_automated, significant_effect |
| Regulation, Article 22(2) | That does not apply where the decision is necessary for entering into or performing a contract, is authorised by Union or Member State law with suitable safeguards, or is based on the person's explicit consent. | gdpr.automated-decision: exception, basis_ref |
| Regulation, Article 22(3) | Where the contract or explicit-consent exception applies, the controller implements suitable measures, at least the right to obtain human intervention, to express one's point of view and to contest the decision. | gdpr.automated-decision: safeguards_offeredgdpr.human-intervention: subject_ref, decision_record_id, request, requested_at, reviewer_ref, result, reasons, concluded_at |
gdpr.automated-decision · Automated decision taken
When: When a decision falling within Article 22(1) is taken, or when you conclude a decision does not fall within it.
| Field | What to put in it | Type | Mapped to |
|---|---|---|---|
subject_ref | Your pseudonymous reference for the person. Never a name, an email or a national number. | your reference | Article 22(1) |
decision_ref | Your reference for the decision. | your reference | Article 22(1) |
solely_automated | Whether the decision was based solely on automated processing. | true or false | Article 22(1) |
significant_effect | Whether it produces legal effects concerning the person or similarly significantly affects them. | true or false | Article 22(1) |
exception | The Article 22(2) exception relied on, or that the decision is outside Article 22(1). | one of contract, union-or-member-state-law, explicit-consent, not-within-article-22 | Article 22(2) |
basis_ref (optional) | Your reference for the contract, the legal provision or the consent record relied on. | your reference | Article 22(2) Article 5(2) |
information_digest (optional) | SHA-256 of the notice given to the person about the automated decision, as given. | SHA-256 | Article 13(2)(f) and Article 14(2)(g) |
safeguards_offered | The safeguards offered with the decision. | list of human-intervention, express-point-of-view, contest-decision | Article 22(3) |
outcome | The decision, in a short phrase. | one line | Article 5(2) |
decided_at | When the decision was taken, UTC. | UTC time | Article 5(2) |
gdpr.human-intervention · Human intervention requested and handled
When: When the person asks for human intervention, expresses a point of view or contests the decision, and again when that request is concluded.
| Field | What to put in it | Type | Mapped to |
|---|---|---|---|
subject_ref | Your pseudonymous reference for the person. Never a name. | your reference | Article 22(3) |
decision_record_id | The record_id of the gdpr.automated-decision record concerned. | your reference | Article 22(3) |
request | What the person asked for. | one of human-intervention, express-point-of-view, contest-decision | Article 22(3) |
requested_at | When the request arrived, UTC. | UTC time | Article 22(3) |
reviewer_ref (optional) | Your reference for the person who reviewed. Never a name. | your reference | Article 22(3) |
result | Where the request stands, or how it ended. | one of pending, upheld, changed, reversed | Article 22(3) |
reasons (optional) | Why the decision was upheld, changed or reversed. | text | Article 22(3) Article 5(2) |
concluded_at (optional) | When the review concluded, UTC. | UTC time | Article 22(3) |
Recording that a decision was outside Article 22(1) is as useful as recording one inside it: it shows the question was asked at the time.
Insurance Distribution Directive · pack idd version 1
Insurance distribution: demands and needs, advice and product information
What an insurance distributor records to show, later, what the customer needed, what was proposed and why, and what information the customer received before the contract.
- The law
- Directive (EU) 2016/97 (Insurance Distribution Directive) (CELEX 32016L0097)
- Kinds
idd.demands-needsdemands and needsidd.recommendationpersonalised recommendationidd.ipid-providedproduct information document handed over- The file
- /packs/idd.json, with an example record for every kind
- How long to keep it
- This pack does not state how long to keep these records. Check the period that applies to you with your supervisor or your professional federation. In Belgium the directive is transposed by the Act of 4 April 2014 on insurance, and the FSMA supervises its conduct rules.
What each article asks, in our words, and where a record answers it
| Article | What it asks (our summary; the linked text is the law) | Recorded in |
|---|---|---|
| Directive, Article 20(1), first subparagraph | Before a contract is concluded, specify the customer's demands and needs on the basis of information obtained from the customer, and give objective information about the product in a comprehensible form. | idd.demands-needs: customer_ref, product_class, information_obtained, demands_and_needs, specified_at |
| Directive, Article 20(1), second subparagraph | Any contract proposed must be consistent with the customer's insurance demands and needs. | idd.demands-needs: proposed_product_ref, consistency_note |
| Directive, Article 20(1), third subparagraph | Where advice is given before a specific contract is concluded, give the customer a personalised recommendation explaining why a particular product would best meet their demands and needs. | idd.demands-needs: advice_givenidd.recommendation: customer_ref, demands_needs_record_id, recommended_product_ref, reasons, document_digest, given_at |
| Directive, Article 20, paragraphs 4 to 9 | For non-life products, give the product information by way of the standardised insurance product information document (IPID). | idd.ipid-provided: customer_ref, product_ref, ipid_version, ipid_digest, provided_at |
| Directive, Article 23 | How information reaches the customer: on paper, or on another durable medium or a website where the conditions for that are met. | idd.recommendation: document_digest, mediumidd.ipid-provided: medium |
idd.demands-needs · Demands and needs
When: Once the customer's demands and needs are specified, before any contract is concluded.
| Field | What to put in it | Type | Mapped to |
|---|---|---|---|
customer_ref | Your own reference for the customer. Never a name. | your reference | Article 20(1), first subparagraph |
product_class | The class of cover discussed, in your own terms, such as motor or home. | one line | Article 20(1), first subparagraph |
information_obtained | What the customer told you, and how you obtained it. | text | Article 20(1), first subparagraph |
demands_and_needs | The demands and needs you specified from that information. | text | Article 20(1), first subparagraph |
proposed_product_ref (optional) | Your reference for the product you proposed, if any. | your reference | Article 20(1), second subparagraph |
consistency_note (optional) | Why the proposed contract is consistent with those demands and needs. | text | Article 20(1), second subparagraph |
advice_given | Whether you gave advice. If true, an idd.recommendation record follows. | true or false | Article 20(1), third subparagraph |
adviser_ref (optional) | Your reference for the person who handled the customer. Never a name. | your reference | – |
specified_at | When the demands and needs were specified, UTC. | UTC time | Article 20(1), first subparagraph |
idd.recommendation · Personalised recommendation
When: When advice is given, once the recommendation is handed to the customer.
| Field | What to put in it | Type | Mapped to |
|---|---|---|---|
customer_ref | Your own reference for the customer. Never a name. | your reference | Article 20(1), third subparagraph |
demands_needs_record_id | The record_id of the idd.demands-needs record this recommendation answers. | your reference | Article 20(1), third subparagraph |
recommended_product_ref | Your reference for the product recommended. | your reference | Article 20(1), third subparagraph |
reasons | Why this product would best meet the customer's demands and needs. | text | Article 20(1), third subparagraph |
document_digest (optional) | SHA-256 of the recommendation document exactly as the customer received it. | SHA-256 | Article 20(1), third subparagraph Article 23 |
medium | How the recommendation reached the customer. | one of paper, durable-medium, website | Article 23 |
given_at | When the recommendation was given, UTC. | UTC time | Article 20(1), third subparagraph |
idd.ipid-provided · Product information document handed over
When: For a non-life product, when the IPID is given to the customer.
| Field | What to put in it | Type | Mapped to |
|---|---|---|---|
customer_ref | Your own reference for the customer. Never a name. | your reference | Article 20, paragraphs 4 to 9 |
product_ref | Your reference for the product. | your reference | Article 20, paragraphs 4 to 9 |
ipid_version | The version of the IPID, as the manufacturer labels it. | one line | Article 20, paragraphs 4 to 9 |
ipid_digest | SHA-256 of the IPID file exactly as handed over. | SHA-256 | Article 20, paragraphs 4 to 9 |
medium | How the IPID reached the customer. | one of paper, durable-medium, website | Article 23 |
provided_at | When it was provided, UTC. | UTC time | Article 20, paragraphs 4 to 9 |
The Worker's own quote ledger (v1) can record what was proposed and priced; this pack covers what stays with you.
MiFID II · pack mifid2 version 1
Investment advice: the suitability assessment and the statement on suitability
What an investment firm records to show what it knew about the client when it advised, what it advised, and that the statement on suitability existed, unaltered, before the transaction.
- The law
- Directive 2014/65/EU (MiFID II) (CELEX 32014L0065)
Commission Delegated Regulation (EU) 2017/565 (CELEX 32017R0565) - Kinds
mifid.suitabilitysuitability assessmentmifid.suitability-statementstatement on suitability- The file
- /packs/mifid2.json, with an example record for every kind
- How long to keep it
- This pack does not state how long to keep these records. Check the period that applies to you with your competent authority; in Belgium the FSMA supervises these conduct rules.
What each article asks, in our words, and where a record answers it
| Article | What it asks (our summary; the linked text is the law) | Recorded in |
|---|---|---|
| Directive 2014/65/EU, Article 25(2) | When providing investment advice or portfolio management, obtain the information needed on the client's knowledge and experience in the relevant investment field, financial situation including ability to bear losses, and investment objectives including risk tolerance, so as to recommend what is suitable. | mifid.suitability: client_ref, service, knowledge_and_experience, financial_situation, ability_to_bear_losses, investment_objectives, risk_tolerance, assessed_at |
| Directive 2014/65/EU, Article 25(6) | When providing investment advice, before the transaction is made, give the retail client a statement on suitability in a durable medium, specifying the advice given and how it meets the client's preferences, objectives and other characteristics. | mifid.suitability-statement: client_ref, assessment_record_id, instruments, advice, how_it_meets_the_client, statement_digest, provided_at |
| Commission Delegated Regulation (EU) 2017/565, Article 54 | How the suitability assessment is carried out, and what the suitability report must contain. | mifid.suitability: knowledge_and_experience, financial_situation, investment_objectives, other_preferences, method_refmifid.suitability-statement: how_it_meets_the_client |
| Commission Delegated Regulation (EU) 2017/565, Article 72(1) | Records are kept so the competent authority can access them readily and reconstitute each key stage, so any corrections or amendments and the contents before them can be easily ascertained, and so they cannot otherwise be manipulated or altered. | mifid.suitability: assessed_atmifid.suitability-statement: assessment_record_id, transaction_ref |
mifid.suitability · Suitability assessment
When: When the information for the suitability assessment has been obtained and assessed, before advice is given.
| Field | What to put in it | Type | Mapped to |
|---|---|---|---|
client_ref | Your own reference for the client. Never a name. | your reference | Article 25(2) |
service | The service the assessment is for. | one of investment-advice, portfolio-management | Article 25(2) |
knowledge_and_experience | The client's knowledge and experience in the investment field relevant to the product or service. | text | Article 25(2) Article 54 |
financial_situation | The client's financial situation, as obtained. | text | Article 25(2) Article 54 |
ability_to_bear_losses | Your assessment of the client's ability to bear losses. | one line | Article 25(2) |
investment_objectives | The client's investment objectives. | text | Article 25(2) Article 54 |
risk_tolerance | The client's risk tolerance, in your own scale. | one line | Article 25(2) |
other_preferences (optional) | Any other preference your assessment method records. | text | Article 54 |
method_ref (optional) | Your reference for the questionnaire or method version used. | your reference | Article 54 |
adviser_ref (optional) | Your reference for the adviser. Never a name. | your reference | – |
assessed_at | When the assessment was completed, UTC. | UTC time | Article 25(2) Article 72(1) |
mifid.suitability-statement · Statement on suitability
When: When the statement on suitability is given to the retail client, before the transaction is made.
| Field | What to put in it | Type | Mapped to |
|---|---|---|---|
client_ref | Your own reference for the client. Never a name. | your reference | Article 25(6) |
assessment_record_id | The record_id of the mifid.suitability record the advice rests on. | your reference | Article 25(6) Article 72(1) |
instruments | The instruments advised, by identifier such as ISIN. | list of your reference | Article 25(6) |
advice | The advice given. | text | Article 25(6) |
how_it_meets_the_client | How the advice meets the client's preferences, objectives and other characteristics. | text | Article 25(6) Article 54 |
statement_digest | SHA-256 of the statement exactly as the client received it. | SHA-256 | Article 25(6) |
provided_at | When the statement was provided, UTC. The log's own time bounds it from above. | UTC time | Article 25(6) |
transaction_ref (optional) | Your reference for the transaction that followed, if any. | your reference | Article 72(1) |
A correction is a new record whose supersedes field names the record it corrects; the earlier record stays in the log. That is how Article 72(1)'s requirement that corrections and earlier contents can be ascertained shows up in the evidence.
Read this before using a pack
What a pack is not
A pack is a data format and a reading of the law, not legal advice, and using one does not make a firm meet any obligation. The summaries of articles are ours, written for orientation; the text on EUR-Lex, linked from each pack, is the law, and national rules and supervisory guidance add to it. We do not decide whether a regime applies to you. We never see your records, handle your customers, or report to your supervisor on your behalf.
The log accepts any kind, packed or not: a pack is a convention you may adopt, never a condition of using the API. The packs, like the specification, are published so that another implementation can read the same records without us. Something wrong in a summary or a mapping? Tell us, and the correction goes in the changelog.