For many financial firms, half of the battle with data isn’t about just using it—it is also about making sure that they are allowed to.

At every bank, there are teams of people that spend countless hours sifting through data licenses and interpreting usage rights, usually answering queries from various parts of the business on whether they have permission to use the data.

“I think it was clear to us at JP Morgan and other financial firms across the industry, that there’s a huge amount of inefficiency and overhead involved in managing a very large and complex contractual estate, all around usage rights and what you can and cannot do with data,” says Alistair Kerr, global head of market data services at JP Morgan.

In January, more than a dozen financial firms, including investment banks, data aggregators, exchanges, and vendors, banded together to resolve these inefficiencies. They hope that by converting contract rights into code they can automate the process, cut costs, and simplify licensing activities across the data supply chain—throughout suppliers, intermediaries, and users.

The weapon of choice for this initiative is the Open Digital Rights Language (ODRL), an extensible markup language (XML) and open-sourced data model used for coding policy expressions, created by the World Wide Web Consortium (W3C), the international community that develops open standards aimed at making sure the web can continue to grow.

Today, the ODRL has already been broadly used to standardize the policy rights of published content for sectors including telecommunications, online publishing, and television and broadcasting. At the beginning of the year, the group of financial firms—which includes notable members such as Goldman Sachs, JP Morgan, Deutsche Bank, Fidelity Investments, the Chicago Mercantile Exchange (CME), and Refinitiv—joined the W3C’s Rights Automation for Market Data Community Group.

Together they are using the ODRL to develop a finance-specific digital rights language, which will later be used to build machine-readable technologies to help remove inefficiencies in data licensing and offer users more agility around their data consumption. They hope to introduce the first version of the digital rights language before the calendar ticks over into 2021.

Although the project is in its infancy, cracks emerged early on.

A lead sticking point is the legality of a machine-readable contract in a court of law. Each legal system is different, but it remains unclear whether a coded contract can be treated as legally binding in litigation proceedings. This is uncharted territory, says Joel Telpner, senior partner at Sullivan & Worcester, an international law firm. The pragmatic question is whether a judge would see it as being in their jurisdiction to adjudicate a case that requires them to read code, or whether code can be enforceable.

If you get into a dispute, you go to court, and the court asks ‘where is your contract?’ and you show them a bunch of code, the first issue is whether the court is going to throw that out

Joel Telpner, Sullivan & Worcester

“Despite the fact that a coder might say nothing can go wrong, something still can go wrong,” Telpner says. “Then, if you get into a dispute, you go to court, and the court asks ‘where is your contract?’ and you show them a bunch of code, the first issue is whether the court is going to throw that out or whether they will look at that, and consider it to be a contract.”

Even members of the working group say it’s not clear how this project will be implemented, and that key concerns, including legal questions, have yet to be fleshed out.

Michelle Roberts, vice president of market data strategy and compliance at JP Morgan, sees ODRL as a technical solution that could help make the licensing process easier. “We’re not looking to replace legal contracts because the sort of richness and the nuance that you get in a legal contract is essential, but it will be very difficult to fully parse all of that into a coded language,” she says. “So, whilst it will be done as close as possible, and it will certainly interpret the intention accurately, it is possible that the legal contract will have more richness than the ODRL version.”

Telpner is also skeptical that a complex contract, often hundreds of pages in length, with subjective terms or changeable interpretations, could be correctly translated into code. This is because machines are programmed to follow a defined set of rules, typically involving “if-then” logic, whereas worded contracts can be heavily negotiated and ambiguous. The concern is whether the legal intent of an agreement can be accurately rendered into lines of code, he says.

What’s Old is New

The concept of digital contracts isn’t new, and some examples already exist in other areas. Self-executable smart contracts built on blockchain technology are being explored for applications in trade and for automating derivatives transactions. However, these digital agreements also evoke legal challenges, says Jo Rabin, head of technology at Deutsche Bank’s Innovation Labs for the UK and Ireland.

“There is a degree of similarity in the discussion [about smart contracts], like to what degree is it binding and enforceable, and are smart contracts even contracts in the legal understanding of the word?” he says.

By definition, a legal contract must include four elements—an offer, acceptance, consideration, and intent—to be enforceable in a court of law. But in the event of a dispute, if those elements are only written in code, it is still unclear whether a court will deem it enforceable, Telpner says.

“If it rains tomorrow at noon, more than five meters in this location, and it is confirmed by some weather service, I will pay you 100 euros—that is an easy contract for you and me to code. But, if you look at a credit agreement, a lending document between a consortium of banks and a corporation, that could be 200 pages—I don’t know how you take something that complicated and highly negotiated, and easily turn it into code,” he says.

“The question is what must happen on an ongoing basis so that new features can be introduced, and if glitches are found over time in existing features, how does that get remedied? We will be putting this to [the] working group because it’s something that we need to address conceptually, sooner rather than later,” he says.

Version control and documenting changes will also be important. For instance, if a regulatory or business audit occurs, businesses must be able to provide the version of the ODRL contract that was used during the time period covered, according to Rabin.

You still need expert market data professionals, machine-readable data products and consistent identifiers to fully understand what and who the licenses are referring to. Machines are fast, but not always smart

Matthew Rawlings, Bloomberg

“[What] the digital rules [stand for] today is obviously an important question, but what is also interesting, but complex, is to be able to go back in time to review what was in force then,” Rabin says.

Another problem arises if the contract is inaccurately translated into code or wrongly implemented, but that is where the exchanges could come in. Stephen Dorrian, director of market data at Cboe Europe, says some banks may rely more heavily on a contract translated by an exchange rather than implementing their own versions.

“If the industry favors that exchanges use a version of ODRL code alongside their contracts, and we certify that this is indeed our contract, then the bank could rely on that far more than if the banks implemented their own versions of ODRL, which could be misinterpreted,” he adds.

Additionally, as more participants join and more changes are made to the ODRL language, all those updates will have to be compatible with the relevant systems throughout the data supply chain. Ensuring changes are reflected in the digital contracts is an issue that still requires further clarity and how this would work, adds Rabin.

Hybrid Theory 

The industry has a lot of experience working with machine-readable licenses and contracts, says Matthew Rawlings, chief data officer, enterprise data at Bloomberg. But “machine readability alone isn’t enough,” he adds.

“You still need expert market data professionals, machine-readable data products and consistent identifiers to fully understand what and who the licenses are referring to. Machines are fast, but not always smart,” he says.

There are examples in the industry of hybrid models. The Financial product Markup Language (FpML), is a standard created by the International Swaps and Derivatives Association that is used to process and confirm the exchange of over-the-counter (OTC) derivatives. Specifically, FpML is used to automate the confirmation process of the overall trade lifecycle for derivatives. 

Sullivan & Worcester’s Telpner describes the OTC example as a hybrid model because most of the agreement, such the master agreement and schedule, between the two counterparties involved in the trade, use a legally worded contract, but the final confirmation step can be done electronically or in a paper format.

Digital contracts work in this instance because a trade confirmation agreement containing simple economic terms can be easily coded, but in cases where the confirmation details are complex, counterparties can opt for the paper method.

An important aspect of FpML is also that it is straightforward to translate the coded rules back into a human-readable text, Telpner says.

“If disputes come up, the only thing the court has to look at is those economic terms because all of the basic terms of the contract are still in the old-fashioned paper world. So that’s a hybrid system where it’s easy to take the FpML and spit out a traditional confirmation. So if you go into court you can take what was done digitally, literally just press a button, and it will spit out the economic terms so that the court can look at them,” he says.

Banks working on the ODRL project have taken note, and some are developing translators to convert coded rules into text. JP Morgan, for example, recently built a prototype of an ODRL-reader internally to enable its non-tech-literate team members to be able to interpret the information.

Chicken and Egg

Many of the working group members agree that the project’s success will be determined by exchange participation. For the project to scale, a significant portion of the exchange community would need to translate their contracts into the ODRL language, which in turn is required to build out the digital rights language further.

“I think everybody must participate. From the vendor and exchange side, ultimately we want them to translate their contracts into ODRL, but until there are tools to generate ODRL, and the language is sufficiently rich to allow the nuances of market data to be captured, then it’s a bit of a chicken-and-egg situation,” says JP Morgan’s Roberts.

The main drivers for exchanges to participate in the project include revenue protection and simplifying the auditing process, according to Cboe’s Dorrian. The working group hopes that if data suppliers translate their contracts into ODRL, they could benefit from machine-readable solutions that ensure their clients are complying with the terms of their contracts.

“The audit process itself could certainly be simplified if, for example, we look at a bank and see that every single application is certified against the ODRL code, then perhaps all the audit has to be is reviewing the logic of that code to make sure that this [reflects] how our policies are drafted today,” Dorrian says.

Similarly, Jamie Crank, general manager of information and connectivity services at the Australian Securities Exchange (ASX), sees ODRL industry adoption as a potential method for minimizing disputes between data suppliers and users. Although audit checks exist to prove an investment firm or intermediary is conforming to the terms of an exchange’s contract, they can damage business relationships. 

Until there are tools to generate ODRL, and the language is sufficiently rich to allow the nuances of market data to be captured, then it’s a bit of a chicken-and-egg situation

Michelle Roberts, JP Morgan

“Market data audits are a necessary tool for exchanges when data reporting is managed through an honesty system. However, they do very little to foster a stronger relationship between exchanges and the market data user base,” Crank says.

The ASX is not a member of the digital rights working group, but Crank says the exchange has adopted DataBP’s e-commerce solution, which is used to manage its data licensing policies and ensure its customers are compliant with those usage rights. DataBP is a member of the working group and is developing an API that will connect to the ODRL. 

Supporters of the project say that exchange adoption of the ODRL, along with ODRL-based solutions, could give rise to new data services for their clients. Currently, data users report to their suppliers that they have used their data in compliance with their contracts. The working group hopes that ODRL products could offer an exchange more granular insight into their client’s usage and enable them to better service those needs.

“If ODRL becomes the standard, it may allow for more granular tagging and a better understanding of data usage,” Dorrian says.

To date, CME has shown the most interest in the exchange community, particularly for contributing to the ODRL proof of concept. 

“We participate in the ODRL working group with others in our industry with the goal of creating new solutions that help reduce the complexity of market data. We remain in dialogue with our clients, our industry, and the marketplace as machine-readable licensing technology develops,” a spokesperson for CME says.

Nasdaq and the ASX both say they are interested in engaging with the initiative as the project evolves. 

If ODRL becomes the standard, it may allow for more granular tagging and a better understanding of data usage

Stephen Dorrian, Cboe Europe

However, as of yet, exchanges have seen little pressure or demand to digitize their contracts. Cboe’s Dorrian says the exchange has received no client enquiries regarding the ODRL to date, and the same goes for the ASX.

“At the moment, ASX is not receiving much appetite or drive for adoption of ORDL within our business. However, we continue to keep a watching brief and would engage in any wider industry consultation as the topic develops,” Crank says.

Garrick Stavrovich, lead product manager for Nasdaq’s Global Information Services division, says that like any project that requires broad adoption, it will be a challenge for those already involved to convince businesses to make this project a priority. 

“Change is never easy, and it is always going to be challenged with the questions: What is the payoff? What is the reward, and does this move the industry forward?” Stravrovich says. In Nasdaq’s case, Goldman Sachs and JP Morgan requested it be involved, he said.

As of yet, only a handful of exchanges are publicly throwing their full weight behind the broader project, and there is a long list of concerns to be addressed before the industry can expect scalable adoption.

These are hurdles the working group will be tasked with resolving in the coming years, but the first glimpse of its progress will arrive in the fourth quarter of this year, when it is expected to roll out the first version of the digital rights language.

For now, at least, it is a matter of wait and see.