FAQs - Transaction Reporting System

A. The Transaction Reporting System (TRS) has been developed to support two important FSA reporting streams:

1. The FSA Markets Division currently collects and analyses transactions reports based on rules dating back to the mid-1990s. Analysing securities transactions is a key regulatory tool in our work to combat market abuse, and transaction reporting is a requirement laid down by the EU Investment Services Directive (ISD). Firms currently report transactions by a variety of reporting methods, of which one is the FSA's own Direct Reporting System (DRS). DRS will be replaced by TRS, with rules updated to enable us to carry out our responsibilities efficiently and effectively, but the other reporting systems remain unchanged.
2. The extension of FSA regulation to mortgages and non investment insurance contracts has significantly increased the number of small firms that we now regulate. The Small Firms Division (SFD) is now responsible for supervising 97% of all firms regulated by the FSA. Because our risk-based approach to supervision means that we will have little direct, regular contact with these firms, our supervisory approach will rely heavily on receiving accurate, timely data:
   
   • to see which products they are selling to consumers (Product Sales Data - PSD); and
   • to ensure that these firms are meeting their regulatory requirements (Retail Mediation Activities Return - RMAR).
   The TRS system will be the data collection system that firms subject to the rules set out in SUP 16 will use to submit their PSD reports to us.

Note: The TRS will not be used to collect RMAR & MLAR data. For information on reporting this data, please refer to Regulatory Reporting.

TRS is essentially a data capture system. It gives users a variety of ways to submit their data – from manual keying to automatic upload. It is browser based so it can be accessed over the internet using an internet browser, such as Internet Explorer. It provides reporting firms with a single, user friendly interface to submit quarterly Product Sales Data (PSD) and daily Markets (SUP17) transactional data.

Data can be submitted manually or it can be uploaded in a pre-defined format using XML. Individual transactions are stored in reports; transactions can be created, amended or cancelled at any time up until submission of the report. Once a report has been submitted, TRS will notify the reporting firm of any validation errors in the report. Following submission, keyed data can still be amended or cancelled for as long as it is stored on TRS (seven years for PSD and 14 days for SUP17 Markets data).

We will use the data submitted to:

• monitor markets transactions for market abuse and other rule breaches;
• monitor firms and to spot trends in individual firms and in the market as a whole; and
• identify firms on which we should target supervisory attention.

For more information on XML please refer to www.w3.org/XML/. Further details about data transfer using XML is also covered in the 'Input/Transfer method' section of the FAQs and in the System to System Interface Guide.

You will be given information on how to access TRS as part of the registration process. At this time you will also be given your UserId and password. If you are planning to use System to System you will be given a URL. In other situations you will be able to navigate to TRS via the FSA website.

We will endeavour to support as many browsers as possible. However, please understand that we are unable to support all web browsers that are currently available or that have since been superseded by more up to date versions.
Please note that for ease of use, the TRS screens have been developed with a 1024 x 768 screen resolution.

The trial facility is provided to help firms to ensure that:

• they can submit a properly created XML file; and
• firms that are keying their data in manually can use the trial area to key-in transactions. Manually keyed transactions are validated at the point of entry so any error messages will be displayed when you try to submit the transaction.

Firms should not use the trial area to test their XML files. Before using the trial area you must test your XML file using an XML parser or via another internal system. You should submit files to the trial area only after this has been done.

The trial environment will be treated as if it is the live environment and so all submissions will be secure.

There is no minimum size required and there is no restriction on the number of test submissions made. Similarly, it is not necessary for firms to submit XML files containing thousands of transactions. However, the file submitted should contain a representative sample of the types of transactions that the firm will submit on an ongoing basis.
We recommend a minimum file size of around ten transactions. At the end of the certification process all XML files will be deleted

The TRS Service Desk will contact you to verify your information and to register you on TRS. You can, of course, contact the FSA TRS Service Desk direct on 0870 0130467 to register.

Each firm that registers for TRS will need to identify a member of staff who will be the Primary/Principal Contact between the FSA and the registered firm for all matters relating to TRS.

For firms who will be manually keying in their PSD data, once we have verified your information we will give you a user ID and password for the live TRS system. As soon as you receive this you can start to use TRS.

Certification only applies to firms who plan to send data via XML.

Certification is the process whereby we check to ensure that the XML file has been created properly and in line with our published schemas. This means that your firm will be certified for live submission even if the file contains low level schema errors and business related errors. You are strongly encouraged to make every effort to rectify any errors before you submit live data to TRS for PSD reporting purposes.

Once we have verified your data and registered your firm we will ask when you plan to send in your XML file to the trial area so that we can check if it is properly constructed. This can be done on the day of registration but should ideally be done within the target registration and certification week.
Please note that if you do not submit your file for certification within the week we may have to reschedule your certification date to a later date.

Once you have submitted your file we will ask you to ring the TRS Service Desk to confirm that this has been done. If the file is properly constructed we will certify your firm, which means we will give you a user ID and password for the live TRS system.
Before this stage, firms should have already tested their XML internally and then submitted it via the TRS trial facility. So we hope to certify most firms at the first attempt. However, if the file is classified as an XML fail, we will ask the firm to send further files with the aim of being able to certify the firm.

There are two basic methods to input transaction data:

1. keying the data in via web forms; or
2. creating an off-line XML file.

The off-line XML method has two different processes:

• Web Upload (HTTPS); or
• System to System (SFTP).

The XML files used in both of these approaches are identical in structure, only the method of transfer differs.

1. Keying in data via web forms (web input)

Under this method, you enter transactional data into a small number of TRS forms accessed through a web browser. As you enter each transaction the fields are validated, and any errors are displayed immediately.

Because you need to input the data manually, this method is betted suited to firms:

• with lower volumes of data and / or without any integrated back-office system;
• that typically use a dial-up method of communication;
• that probably do not have a detailed IT understanding or a dedicated IT resource / computer support person available in their organisation.

2. Off-line XML input (Web Upload or System to System)

There are several ways an XML file containing transactional data may be created. Firms may have:

1. an existing back-office system that has been modified to produce the XML file;
2. procured a new system to produce the XML file; or
3. identified a method of ‘manually’ creating an XML file from current system data, by exporting from MS-Excel for example.

Having created an XML file, you have to decide whether to use Web Upload or System to System to transmit this XML file to the FSA. You do not need to do this purely because of volumes; you may decide to use one approach because it is more convenient.

The advantage of the System to System approach is that the data transfer can be initiated by a form of automated script that can be scheduled to run at the appropriate time. For example it could be that an XML file of transactions is assumed to have been captured in a known location at a specific point in time ready for the 'automation' script to be enabled to transfer this file to us. This method would not be size constrained, as it could be used to transmit any size file.

Web Upload can be used to manually send any XML file. However, there is a file size threshold at which point the Web Upload becomes too slow. It is not possible at this time to put an exact figure on this and it depends on the product type you are reporting on and the type of communications approach you are using. For guidance, in data sizing terms, Pure Protection is very small and Mortgages is significantly larger; in file transmission terms, a dial-up modem is very slow, broadband or fibre-optic connections can be very fast.

System to System approaches tend to be more efficient as they compress the data to make the size of the data file to be transmitted as small as possible and so decrease the file transfer time.

If possible, we may publish further guidance on indicative transmission time estimates for each method and their impacts on equipment. However, firms need to decide for themselves the impact of introducing TRS into their organisation.

We positively encourage you to verify the validity of your XML file by running the file through an XML parser. This will avoid unnecessary delays in uploading XML files that may contain errors that need to be resolved and ultimately reduce the amount of future effort in resolving data errors.

For PSD only To avoid long transmission times, PSD files could be uploaded on a periodic basis rather than waiting until the 20 day reporting period to submit the data from a complete quarter.

Web Upload

For this, you generate an XML file outside TRS and then use TRS to upload the file. Through the web browser, you can access the TRS XML upload screen and the browse facility used to navigate to the appropriate path and file to identify the file to be uploaded. Once you have submitted the file, TRS will validate it and, when the validation process has finished, will provide feedback while you are still online. This approach is often described as ‘synchronous’.

For users of Internet Explorer, within the browser window, the status bar will show the progress of the upload, and in all browsers a series of dots displayed will show that the validation process is active.
For the reasons already explained, this type of input could be considered by firms:

• with only moderate volumes of data, with some form of back-office system or package that generates an XML file;

• with some form of medium speed communication such as broadband;

• that probably have a basic IT awareness or limited access to a dedicated IT resource available in their organisation.

System to System

This also involves generating an XML file outside the TRS application, but it uses an external method of file upload and download of the validation results using Secure File Transfer Protocol (SFTP). Each of these steps are distinct phases – the upload of data and the download of results are separate SFTP sessions. Between these sessions, firms must allow sufficient time for the file to be validated and parsed. (This approach is very often described as 'asynchronous'). See the other questions covering the detail of the SFTP process and downloading validation results.

This type of input could be considered by firms:

• with large volumes of data generally with some form of back-office system;
• with either a medium/high speed communication such as broadband or fibre optic connection;
• that probably have a dedicated IT resource available in their organisation.

The major benefit of this approach is that the data file transmitted as part of the SFTP process is compressed. So the transmission time is significantly shorter.

To avoid doubt, we have used the terms ‘lower’, ‘moderate’, and ‘large’ as an indicative sizing threshold and firms should decide for themselves the real threshold based on their own profiles.

If you are planning to use an XML method of data input, you should download both the XML Schemas and a copy of an XML parser / validation process, so your files can be validated off-line before uploading to us. For System to System, you will also need to acquire a copy of a Secure File Transfer Protocol (SFTP) client.
Your method of data input will be agreed as part of registration.

XML Schema files, that define the contents of the report files to be transferred, are available at:

For PSD: Download all PSD schemas [ Zip file | 493 KB ]

For Markets: Download all Markets schemas [ Zip file | 613 KB ]

Please note, the guidance notes available on the use of these schema files and how to create report files (in XML format) are also available for download.

Every XML Report file that is sent to the FSA must be validated against the relevant TRS XML Schema available on our website. So it is necessary for firms to acquire appropriate software. We cannot recommend a particular software package, but the following link lists some of the more well-known versions: www.garshol.priv.no/download/xmltools/cat_ix.html#SC_XMLVal

You will need a Secure File Transfer Protocol (SFTP) client, software that is generally available in two forms.

• One version uses a Windows interface, whereby the screen is typically (although not always) divided into two windows, and you transfer files to us by dragging files with a mouse.

• The other version uses some form of command level interface, by which a call to STFP may be performed as a script.
We cannot recommend a particular package, but the following links describe some of the free versions of this software: www.thefreecountry.com/webmaster/freeftpclients.shtml or www.uk.openbsd.org/openssh/windows.html.

If you have expressed an interest in using this method of communication, we will contact you during the roll-out period to let you know the settings for connecting to the trial area. Once you have certified, you will be given the setting for the main application.

TRS imposes a limit of approximately 35MB for files submitted within a Web Upload xml report. Other factors – such as speed of connection, sesion timeout and current load on the system – will restrict the maximum size from a practical point of view, and because of this submission should be aimed to be completed within 30 minutes.

Multiple files are acceptable from a single system, as long as the return indicates unique identifiers for each file.

Using XML can increase the size of the file being transmitted – by 8 to 15 times the actual data content. This will affect the time the transmission takes, along with other environmental factors such as the size and type of communications link used. Firms need to decide for themselves the impact of introducing TRS into their organisation.

The following is an example of an SFTP upload script:

1. open trs.fsa.gov.uk
2. 15782
3. Abc123
4. cd report_upload
5. lcd trs_transmit
6. put filename.xml
7. quit

For more information see the System to System Interface Guide.

The following is an example of an SFTP validation script:

1. open ftp.trs.fsa.gov.uk
2. 15782
3. Abc123
4. cd result_download
5. lcd trs_results
6. get filename_rpt.xml
7. quit

For more information see the System to System Interface Guide.

All data transmitted, regardless of approach, will use a ‘secure’ method of transfer. Web input and Web Upload will use HTTPS and System to System will use SFTP (as opposed to HTTP and FTP; the ‘S’ indicating a secure connection). These secure methods of transfer use encryption processes before sending the data and appropriate decryption processes at the receiving end. So the communication channel performs the encryption and not any proprietary vendor software outside of TRS.

Further technical reference and protocol information is available on:

www.w3.org/Protocols/
www.w3.org/Protocols/rfc959/
www.faqs.org

You can pass your XML file to a local validation process before committing this file to the FTP server. To complete this exercise, you should download the appropriate FSA XML Schemas, and also a copy of an XML parser / validator and use the XML schema to validate an appropriate XML file.

The System to System method of data transfer involves a physical disconnect between the two stages (i.e. XML upload and the Validation report download). So following transfer and disconnection, there is a requirement to reconnect to download data validation and data transfer results.

This information in the form of a validation results XML file will be produced detailing the results of the XML upload and any errors identified. This file will be available for download and local processing once the validation process has completed. Please refer to the Validation Replies Schema and the Validation Replies Data Reference Guide for more information.

Web Upload results will be reported back automatically once the upload and validation have completed and been processed. System to System upload will require you to query the data transfer results. There is no alert mechanism to inform the sender that a file has completed verification. So when using the System to System interface you should leave 30 minutes after uploading before requesting a subsequent download of the validation results.

The answer depends on the method that you use. Some validation will take place at the time of data entry, e.g. if you enter data via web forms. The turnaround once submitted will depend on the size of the data file and the number of errors encountered. The design aim is to respond within 30 minutes but this has still to be tested and confirmed.

Re-submit only corrected records.

Submissions will need to be corrected and resubmitted in the same period.

Sending an accepted file more than once will cause duplicates to be created. The system is only able to detect that records are duplicates when they are submitted on the same file.