Table of Contents

Date

08 Feb 2018

Actions items

Add new action items here.

Agenda

Meeting notes

Attendees

Aaron Williamson

Ian Stocks

Johan Sandersson

Brett Campbell

Bruce Skingle

Notes

JS: I put out a vote on security object – get your votes/comments in. Same with Country object; we have more votes there. Chasing down Vincent & Lawrence Miller to bring in someone from Symphony LLC product team. Unclear whether WG will be in new program or this working group. On the country object, it’s good to have Bruce and Ian on the call, since you’ve had the strongest opinions on this topic. I’d like to hear more of your thoughts and have the LLC team consider them.

IS: My main point is that there are some restricted country codes referenced in the wiki that are already in use – EU and UK – that I think should be accepted. EU is used in ISIN and probably hundreds of individual ISINs.

JS: So this would be for parity with ISIN? Or is this a technical need to dissect the ISIN and use that code?

IS: To me it doesn’t make sense to make the new standard more restrictive than something in widespread use.

BS: It’s an ISO standard that says that. I think it’s sterile to have this conversation absent participants who want to send and receive these codes. If all participants’ systems use non-standard codes but they’re all compatible, it would make sense to codify those. But if lots of different firms have different internal incompatible systems, it makes sense to be more restrictive in a standard for interoperation.

IS: I’m not disagreeing with you, I just think the restricted codes on that page should be accepted: officially assigned and exceptionally reserved.

BS: But the meaning of “exceptionally reserved” in that standard means “should not be used.”

JS: Ultimately it would be best if everyone uses the officially assigned ISO codes and that those with a different internal representation can do a transformation.

IS: Look at what it says for EU: it’s used in ISIN.

BS: EU as a country code?

IS: Yeah.

BS: As I say, I think we should adopt what people actually want to use. It seems to me that using multiple codes for one country is confusing because it means receivers have to decode two codes.

IS: I’m more concerned about EU, because the EU is an issuer of securities, including the European Stability Bonds.

JS: I checked that with our symbology team and we have those listed as coming from Luxembourg, which seems to make sense from a legal standpoint.

BS: You may be right, Ian. I’m reading the ISO page and it says exceptionally reserved codes should not be used for any other country, not that they shouldn’t be used. I’m just saying we should follow the ISO standard, and maybe my initial interpretation was wrong. Does Thompson Reuters provide a country decode service or do they refer to this standard?

IS: To be honest, I don’t know. I’m not sure I’m disagreeing with your position, just your interpretation of the ISO standard.

BS: And if there’s a general consensus that people are comfortable dealing with multiple codes for the same country, I think that’s fine.

BC: Speaking from Citi’s perspective, we definitely use EU and we’re not going to change what’s in our systems. I’d say accept everything because traders don’t care what’s happening in the backend. They’re just going to make it work.

JS: Should we cancel the vote? Are we in agreement that we should accept “exceptionally reserved.”

BS: I think all we’re saying is that the correct interpretation of the ISO standard is that exceptional reserved codes can be used, we don’t need to cancel the vote.

JS: Ok, I don’t think we need to cancel the vote, because we have the core group here and we’ve all voted to approve. Please submit your votes if you haven’t.

BS: I’ll do that right now.

JS: I’d expect a change in your vote now then, Ian.

IS: Yep, absolutely.

BS: Johan, why don’t you include a note on that page with this interpretation.

JS: Yep, I will do that. The other related item is, in terms of enforcement, if someone sends a non-acceptable code, where should that be validated?

BS: We have talked about this a bit internally. My view is that the platform needs to do some basic validation. We need to validate that the type identifiers are present and well-formed, because without that, we can’t route the object to the correct renderer to display it. There’s a limit to what we can realistically enforce in terms of valid messages, because of the encryption. So the options available are: 1) Put validation in the API agent that rejects messages sent by API users that do not conform to the standard. But that’s a process running on the customer’s system and we can’t stop them from disabling those checks and sending invalid messages into the system.

AW: But that would take an administrator?

BS: Well, you could also mess with the Javascript in the web client. So it’s not feasible to prevent messages from getting into the system. We could prevent them from being rendered in the standard client, but there’s nothing to prevent people from using their own client.

AW: Would it make sense to have a best practice that renderers should highlight invalid data for the user?

BS: The point of having different renderers is that they handle different data differently, so you might differentiate on how you render invalid data. And you can’t really prove the correctness of the data holistically. I’m not sure what the benefit would be.

JS: Let’s say someone who hasn’t read the spec uses the three-letter country code.

BS: I don’t think there’s anything we can do to stop that, because that ought to happen on the server and we don’t have visibility into it. The encryption changes everything.

AW: It sounds like this is ultimately the job of the receiver.

BS: I would agree with that. Supposing you receive invalid data, what is the renderer going to do? It could display a warning, but otherwise what would you do differently?

JS: My interest is more in the sending side. If someone’s sending invalid data, shouldn’t they be limited or warned?

BS: Generally that seems like a good thing, but now we’re just into a question of prioritization of feature requests. We could certainly make the case that it should be included if that’s what this group thinks is best.

I should mention that we’re working on code generators for sending and receiving data on the wire, and my hope is to expand that to support structured objects and to provide code generation for code that could be used in a bot to parse an object and give you data that represents that structured object that’s more convenient than some internal representation. But there’s no timeframe for that.

JS: So this structured object JSON schema. What can that do in terms of the country object.

BS: What could be implemented is that we could write a JSON schema for the country code – you see the definition of a time of day with a regex validating the data – we could do the same thing for this country code, validating them against an enumeration of acceptable ISO codes. And you could run that validator against the data you receive to determine if it’s valid.

JS: What’s the general feeling about that? Should we add that for the country object? Should it just check for a two-letter code or validate against the list?

BS: I’d say we should include the enumeration of valid codes.

JS: Bruce, could I ask you to add that?

BS: Yes, I can do that.

JS: Ok, I think that would be excellent. It would close the bag for me and my understanding of how we can enforce a value following the standard.

BS: Yep, and there’s a new home for this in a Foundation repo that I can link to from that Confluence page.

JS: Ok. Progress! Any other business?

Attendees