About new feature in DSS 12.1 on ISO 15022 35B field
This new feature:
"Corporate Actions ISO 15022 35 B changes; x character set restriction relaxed to correctly display RICs and Ticker Symbols with unsupported characters. CIN Code added to Standard Events."
Why relaxed the X character set? That will crash ISO decoder if any non-ISO characters... Why not using the SWIFT EBCDIC code for all those special char?
I have an open case about an issue with a $ sign in a 35B field. The $ is not allowed in the 35B format. The $ is reserved to separate different ISO messages.
I have also another issue in the output of CorporateActions extraction in ISO from DSS, some CrLF in the output are " r n" instead of "\r\n". ThomsonReuters Dev team are on it but no ETA for the moment...
Regards
Stephane
Best Answer
-
Thank you very much for your feedback Stephane.
Per MDPUG Principle 14 ("Valid Characters for the description of the Security"):
"...The group confirmed that where they are not using FIN for delivery, they would not be limiting the characters used to those of the ‘x character set’. It is a requirement and valued added service to provide the exact legal name of a stock/company, for example..."
I raised this point with the MDPUG on May 15th 2018 - seeking clarification in relation to RICs and Ticker Symbols in particular.
The outcome was as follows:
"For /RICC/ and /TS/ the conclusion was that Data Source Schemes were exempt from the ‘x character set’ restrictions requiring the use of escape sequences for outliers.
Examples are:
- /RICC/WFE_pa.N (underscore)
- /RICC/DEA0D0P4=MU (equals)
- /TS/Y&G (ampersand)"
In keeping with this, the intention of DSS 12.1 was to relax the existing constraints for /RICC/ and /TS/ specifically and exclusively.
Unfortunately, as a result of an undetected defect, the scope of application was wider and I apologise for the associated disruption.
I shall request that the underlying policy matter be added to the agenda of the next MDPUG Meeting (July 31st) for further discussion and review our plans in light of the conclusions.
The end of message marker is "-}$" and that string, with that meaning, would not arise within 35B.
Best Regards,
Paul Barnes
1
Answers
-
Hi Paul,
Thanks for the reply.
Are you sure about the end of message? For me the end of message is "-}", the "$" is here to separate messages... as we don't have on the last message when we get multiple messages.
Regards
Stephane
0
Categories
- All Categories
- 6 AHS
- 37 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 59 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛