1. Transaction Reporting: Exception Handling
24 January 2018
Version 1.0

2. This guide covers the following aspects of the NEX Regulatory Reporting Portal…
Transaction: Failed Validation
General guidance
Addressing records individually
Addressing records in bulk
Transaction: Failed Eligibility (MiFID)
Transaction: Regime Rejected
Transaction: Processing Errors
31 December 2018
Confidential

3. Transaction: Failed Validation – General Guidance
Drilling into Failed Validation records, the user is presented with a list of all records which have failed in the HUB. The state of the individual record will show the type of failure, including, amongst others Determination, Enrichment, (HUB) Validation and ARM Validation (for MiFID only).
Depending on which state the record is in, the Failure Reason will show either the field and reason for the failure (if there is only one reason) or the number of reasons for the failure (if multiple failure reasons).
Users can opt to view a particular record in full either by clicking anywhere along the relevant entry in the table, or by hovering over the Trade ID / Transaction Reference Number choose to open the record in a new tab/window.
Each of the groups can be expanded to present a list of the subset of records within that group. This is done by clicking anywhere on the row.
Users then have the option to select an individual record or alternatively hover over the Trade ID / Transaction Reference Number to open the record in a new tab or window.
Alternatively a user may toggle to the Failure View to see a summary view of (ARM) validation and enrichment failures.
Initially users are presented with a summary of the status of records submitted today on a regime basis.
If any records are in Failed Validation, users can view the details of the records by clicking the red number to go to the record list view.
31 December 2018
Confidential

4. Transaction Failed Validation: Individual Records
When viewing an individual record, the field/reason (if only one) or number of failures will show in the header.
Once submitted, the page will automatically update with the following updates:
state in the header section;
details of the changes recorded in the Audit Log;
all fields greyed out as they will not be editable while the record is being re-processed.
The page can be manually refreshed at any stage or users may chose to track the revised status through the Sources page.
Clicking ‘Submit Edits’ results in a pop up box to confirm the user wishes to proceed.
Submitting will record the updated values in the database and audit trail. It also sets the record to be re-validated, and re-enriched if appropriate.
Clicking ‘Revert’ will return the user to the record with the updated text still displayed but not committed to the database. This allows the user to continue editing before any submission, or to discard the changes.
If a user feels they have incorrectly updated any fields, they can use the ‘Discard Edits’ button to undo all changes.
Alternatively, once a user has updated all relevant information, they can choose to ‘Submit Edits’.
For (ARM) validation failures, the section containing the failed field(s) will be indicated.
For (ARM) validation failures the individual failed field(s) will also be highlighted, together with the failure reason(s) visible below.
For users with the necessary modify permission, any fields which aren’t greyed out can be edited if the record is in a failed state, regardless of whether the field necessarily failed validation per se.
31 December 2018
Confidential

5. Transaction Failed Validation: Bulk Records
The buttons apply the selected action to all records within the particular group.
Note that as the same record may have failed for multiple reasons, a record can belong to multiple groups.
As expected, the Not Reported button would move the records to not reported.
The reprocess button will send the records to be re-enriched (MiFID only) and re-validated. This is useful if, for example, reference data has since been updated as the new data will be applied.
Pressing either button will result in a pop up asking the user whether they wish to proceed with their selection.
The user may choose to ‘Submit’ or ‘Cancel’ the updated state for the chosen records.
All submissions are recorded in the audit log for the individual records, which is accessible via the Portal.
Users with the relevant permission, will see 2 buttons on the Grouped Failure screen:
Reprocess and Not Reported.
Before using either button to update records, we would recommend expanding the group and checking the individual records to ensure the same action should be applied to all.
31 December 2018
Confidential

6. Transaction Failed Eligibility (MiFID): Bulk Records
The buttons apply the selected action to all records within the particular group.
As expected, the Not Reported button would move the records to not reported.
Override would force the records to the next stage which would be validation in the ARM, prior to sending to the NCA.
The Reprocess button will send the records to be re-enriched and re-validated in the HUB. This is useful if, for example, reference data has since been updated as the new data will be applied.
Pressing any of the 3 buttons will result in a pop up asking the user whether they wish to proceed with their selection.
The user may choose to ‘Submit’ or ‘Cancel’ the updated state for the chosen records.
All submissions are recorded in the audit log for the individual records, which is accessible via the Portal.
Users with the relevant permission, will see 3 buttons on the Grouped Failure screen:
Not Reported, Override and Reprocess.
Before using any button to update records, we would recommend expanding the group and checking the individual records to ensure the same action should be applied to all.
For MiFID records, as with Failed Validation, users can drill into records showing as Failed Eligibility on the Sources page.
Initially users will see the record list view but have the option to toggle to a grouped failure view.
31 December 2018
Confidential
Confidential
31 December 2018 6

7. Transaction Regime Rejected: Individual Records
Clicking ‘Submit Edits’ results in a pop up box to confirm the user wishes to proceed.
Submitting will record the updated values in the database and audit trail. It also sets the record to be re-validated, and re-enriched if appropriate.
Clicking ‘Revert’ will return the user to the record with the updated text still displayed but not committed to the database. This allows the user to continue editing before any submission, or to discard the changes.
Once submitted, the page will automatically update with the following updates:
state in the header section;
details of the changes recorded in the Audit Log;
all fields greyed out as they will not be editable while the record is being re-processed.
The page can be manually refreshed at any stage or users may chose to track the revised status through the Sources page.
Alternatively, once a user has updated all relevant information, they can choose to ‘Submit Edits’.
If a user feels they have incorrectly updated any fields, they can use the ‘Discard Edits’ button to undo all changes.
When viewing an individual record, the reason for an NCA or TR rejection will show in the indicated section.
For users with the necessary modify permission, any fields which aren’t greyed out can be edited if the record is in a rejected state, regardless of which field was rejected by the NCA/TR.
31 December 2018
Confidential

8. Transaction Processing Errors
Records may fall into the Processing Error state if there has been an unhandled exception during processing.
Such occurrences should be rare and the reason may be varied.
We would recommend contacting our Support teams for investigation and resolution of such issues.
31 December 2018
Confidential

9. Thank you Should you have any questions, please contact nrrsupport@nex
Thank you Should you have any questions, please contact
All information contained herein (“Information”) is for informational purposes only, is confidential and is the intellectual property of NEX Group plc and/or one of its group companies (“NEX”). The Information is directed to Eligible Counterparties and Professional Customers only and is not intended for Retail Clients (as each term is defined by the rules of the Financial Conduct Authority ("FCA")) or equivalent in a relevant jurisdiction. This Information is not, and should not be construed as, an offer or solicitation to sell or buy any product, investment, security or any other financial instrument or to participate in any particular trading strategy. The Information is not to be relied upon and is not warranted, either expressly or by implication, as to completeness, timeliness, accuracy, merchantability or fitness for any particular purpose. All representations and warranties are expressly disclaimed. Access to the Information by anyone other than the intended recipient is unauthorised and any disclosure, copying or redistribution is prohibited without NEX’s prior written approval. If you receive this information in error, please immediately delete all copies of it and notify the sender. In no circumstances will NEX be liable for any indirect or direct loss, or consequential loss or damages including without limitation, loss of business or profits arising from the use of, any inability to use, or any inaccuracy in the Information. NEX and the NEX logo are trademarks of the NEX group. Certain NEX group companies are regulated by regulatory authorities. For further regulatory information, please see ©NEX Group plc 2017