What is TwoWay processing under GDPR Article 28?
Under GDPR Article 28, a buy-side compliance officer may ask: "Will this pilot process broker communications only on our documented instructions, and can the processing be covered by a data processing agreement?" That is the right starting point for assessing an AI tool that turns broker chat into structured trading data.
TwoWay is designed to structure communications from fixed income trading workflows, including quotes, indications and fills. Those messages may contain information about instruments, prices, sizes and counterparties. They may also contain information relating to identifiable individuals, such as a broker's name, email address, user identifier, signature, telephone number or communication history.
GDPR Article 4 defines personal data broadly as information relating to an identified or identifiable natural person. It also defines processing, controller and processor. Whether a particular broker message contains personal data depends on its content and context. A message containing only an instrument identifier and price may not raise the same question as a message linked to a named trader or broker account.
For a typical pilot, the buy side may determine the purposes and means of processing its trading communications, while the technology provider processes those communications on the firm's instructions. That may support a controller and processor structure, but the correct allocation depends on the proposed use, the parties' decisions and the relevant data flows. It should be documented rather than assumed.
What Article 28 documentation should cover
Article 28 requires a processor relationship to be governed by a contract or other legal act. The documentation should describe the subject matter and duration of processing, the nature and purpose of processing, the types of personal data, the categories of data subjects, and the controller's obligations and rights.
For a trading data pilot, the practical review should also address how the contractual requirements apply to the product configuration. Questions commonly include:
- What communications and metadata will be ingested?
- Will the system retain message content, structured outputs, audit logs or user activity data?
- What documented instructions may the buy side provide during the pilot?
- Which personnel may access the data for support, security or service improvement?
- What assistance is available for data subject requests, security incidents and compliance information?
- How will data be returned or deleted when the pilot ends?
- Are any subprocessors involved, and how are they disclosed and managed?
Article 28 also requires processors to act only on documented instructions, ensure confidentiality, implement appropriate measures, support the controller's obligations where applicable, and make information available for demonstrating compliance. The agreement should not be treated as a generic procurement attachment. It should correspond to the actual architecture, access model and retention settings used in the pilot.
EU data residency is a question about the whole data path
"Is the data hosted in the EU?" is useful, but it is not sufficiently precise for a vendor assessment. A buy-side team should ask where raw communications, extracted fields, embeddings if used, logs, backups and support records are stored. It should also ask where personnel or service providers may access them remotely.
GDPR Articles 44 to 49 govern transfers of personal data to third countries. If a pilot involves a transfer outside the European Economic Area, the parties need to identify the relevant transfer mechanism and assess the surrounding safeguards. Standard Contractual Clauses may be relevant, subject to the facts of the transfer and the applicable GDPR requirements.
For a Paris based provider, the location of the legal entity is one fact in the assessment, not a substitute for mapping the processing environment. A compliance officer should request a clear data flow description that distinguishes the provider's entity, hosting locations, subprocessors and support access locations. EU residency may reduce some transfer questions, but it does not remove the need to document security, access and deletion controls.
How broker communications interact with MiFID II records
GDPR analysis sits alongside financial services record keeping. MiFID II Article 16 requires investment firms to keep records of relevant telephone conversations and electronic communications relating to orders and transactions. The framework includes a five year retention period, subject to the applicable regulatory requirements and any longer period required by a competent authority.
ESMA guidelines on record keeping for MiFID II are relevant when a firm decides how communications should be captured, retained and made available for supervision. A structured parsing tool should not be treated as automatically replacing the firm's source record, retention system or supervisory controls. Its output may be an additional structured representation used for workflow, search or analysis.
This creates an important design distinction. The firm needs to establish which system is the authoritative record, how the original communication is preserved, and whether the structured output can be reconciled to it. Retention for MiFID II does not by itself establish an unlimited GDPR retention period. The firm should document the purpose for each data set, its retention rule and the reason the period is necessary.
A pilot assessment in practice
Consider a compliance officer at a buy-side firm reviewing a proposed pilot. She asks five specific questions before approving access to a broker communication feed:
- Do the communications contain personal data under Article 4, or only trading information?
- Is the firm the controller and is the provider acting as processor for the defined activities?
- Which Article 6 lawful basis supports the relevant processing?
- What DPA terms apply under Article 28, including deletion, confidentiality, security and subprocessors?
- Where are the raw messages, structured outputs and logs hosted, and will any transfer mechanism be needed under Articles 44 to 49?
The product team should be able to answer these questions with a processing description rather than a broad statement that the platform is "GDPR compliant." The assessment should connect each answer to the pilot scope. For example, if the pilot is limited to parsing selected broker messages for internal trade workflow, that should be distinguished from later uses such as model training, product analytics or cross customer benchmarking.
The French data protection authority, CNIL, is relevant to a Paris based provider and to French organisations assessing their data protection obligations. CNIL materials may inform the firm's broader compliance work, but the pilot review still needs to be based on the actual processing activities, contractual terms and technical configuration.
What the pilot does and does not settle
A structured parsing pilot does not require the buy side to assume that every piece of trading information is personal data, nor does it automatically require a new lawful basis for every internal workflow. It does require the parties to map the data, identify whether personal data is present, establish the controller and processor roles where applicable, document Article 6 reasoning, and put appropriate Article 28 terms in place before processing begins.
There are genuine areas of uncertainty. Whether a broker chat contains personal data under Article 4 can depend on whether the message, identifiers or surrounding metadata relate to an identifiable person. A named broker's communication clearly raises a different issue from an anonymised instrument and price record, but the boundary is not always obvious in a live trading environment.
The lawful basis for archiving communications can also require careful analysis. Article 6 includes legitimate interests, contractual necessity and legal obligation as distinct bases. A firm may consider legal and regulatory record keeping, performance of a contract, or its legitimate interests in preserving evidence and managing trading operations. The correct basis depends on the purpose, the parties' roles, the necessity analysis and the firm's balancing and transparency work. MiFID II retention obligations should not be treated as a universal answer to every GDPR question.
For a pilot integration, the practical next step is an Article 28 DPA review alongside a short data flow and retention schedule. The buy-side team should ask TwoWay to map each message source, output, hosting location, access category and deletion event, then confirm whether the proposed lawful basis and transfer position remain supportable for the pilot's actual scope.