Mark Montoya is one of the longest standing leaders in the U.S. regulatory sector working on the transformation of government documents into searchable, structured data. Mark took us behind the scenes on the FDIC’s call report modernization project in the early 2000s, the first mandatory electronic filing system for financial data in the US, and told us why he is optimistic about future structured data initiatives.
Hudson Hollister
Mark Montoya, Chief of Data Strategy at the FDIC, thank you so much for joining us.
Mark Montoya
Thanks for having me.
Hudson Hollister
Mark, you are one of the longest standing leaders in the regulatory sector in the United States in the transformation of government documents into searchable, structured data. Tell us about how you came to be the primary executive sponsoring the transformation of banking call reports from PDF into XBRL (eXtensible Business Reporting Language) in the mid 2000s.
Mark Montoya
In 2000 and into 2001 FDIC was researching a way to modernize their financial collection system, along with the Federal Reserve Board and the Office of the Comptroller of Currency.
At the time, XML was big. We looked around at various technologies, even at JSON, and eventually we went to a meeting in lower Manhattan in New York and learned about XBRL. It was unique — an XML language used to collect business reporting information, it had monetary items, and they had credit and debit in there. So we looked at XBRL for modernizing the call report.
In the beginning, it was difficult getting a PDF file into an intermediate format and then eventually getting into an XBRL instance document. It took a lot of work just to do that. Early on, I was doing a lot of work in WordPad, then eventually I moved over to XMLSpy and an XML processor called Oxygen. There were no XBRL processors at the time so we did a lot of stuff manually. With the help of the XBRL Consortium, we tested our instance documents and we went from there. The rest is history.
Hudson Hollister
And what a history it is. Banks began reporting their quarterly call reports in XBRL instead of PDF. Let’s talk about some of the consequences. First, what were the consequences for the FDIC and the other agencies in the Federal Financial Institutions Examination Council? What was different for the analysts that had to use these reports?
Mark Montoya
That’s a great point. One thing that’s unique about this implementation we did with XBRL is instead of having the banks tag information, like a lot of entities do with the SEC’s 10-K and 10-Q, we had relationships with software vendors. Back in the 80s, FFIEC started collecting the call report in a very small mainframe electronic text format. When we started moving to XBRL, we had an agreement with nine software vendors to have the XML information built into their software. That made it default for, at the time, around 8,100 banks.
All the banks saw was their original software interface where they would enter their information. Then the software would send an XBRL instance up to our central data repository and their web services when they finished their report. What was different for the banks is that we made them responsible for their own data. In the bank’s software, they had to pre-validate a lot of their information before they sent it up to the regulatory agencies. That meant the data came in much cleaner.
It’s hard to believe but using XBRL, the data was 100% clean. What we mean by that is there were no validation errors, there were no math errors, and it was all done through the XBRL formulas. The data improved because the system allowed the banks to send in their validation criteria with the message saying why they’re failing the criteria.
The ramifications were that analysts then started to be able to focus on true analysis, instead of worrying about talking to the banks and calling the banks to tell them the resubmit. They got to analyze the clean XBRL data and sometimes didn’t even have to call the banks, they just accepted the call record.
Hudson Hollister
When the banks were required through their software vendors to begin reporting these quarterly reports as XML instances instead of as PDF documents what was the difference for the bank?
Mark Montoya
It created a burden reduction. At the time, with the PDF files, the banks would have had to fill out the whole call report of perhaps 2,100 items. It’s gotten bigger since Dodd Frank Act, the CARES Act, and capital requirements. But before, they had to fill out everything in a PDF file, which means they had to put either “NA” or “null” or “zero” in items they didn’t need to fill out.
Through XBRL formulas and the software we designed a way for the banks to answer questions up front. Are you over 300 million? Do you have foreign offices? The set of questions we asked up front filtered down what the bank had to submit to us. That was new for the banks. They previously filled out all the information. Suddenly they’re like, “Oh, we used to fill out that schedule in the past.” But the new XBRL system, based on the reportability rules, showed what sections they did and did not need to fill in. The software would just blank it out.
A lot of banks would go from 2,100 items they used to fill out to maybe 1,100 or 800 items. Essentially through the software, and through this process, we reduced the amount of items that the bank had to submit every quarter. That’s burden reduction. It helped out a lot.
Hudson Hollister
Cheaper compliance for the banks and better reporting for the agency.
Mark Montoya
Exactly.
Hudson Hollister
After you pursued that transformation from unstructured documents into structured XML for these quarterly call reports that banks are obliged to file, there were other implementations of that same change in the US federal government in the regulatory sector. Notably, the SEC did the same thing in 2009 and the Federal Energy Regulatory Commission (FERC) pursued a similar transformation, culminating two months from now.
Why do you think that the wholesale transformation from documents into structured XML has only happened three times across different kinds of regulatory reporting requirements?
Mark Montoya
I think there are two aspects. First, it does cost money. Either it’s going to be on the respondent, like the banks, or it’s going to be on the entities, software vendors, or the agencies. Someone’s going to have to pay for it. A lot of times the number-crunchers see the cost but they don’t see the bigger picture of how it’s going to reduce burden for the respondents and how it’s going to actually help the agency in the future. That’s one of the reasons why you don’t see as many implementations of the structured data collection and projects.
The second aspect is that people just don’t understand the benefits. The FDIC implementation of the call report using XBRL, the SEC, and the FERC are great use cases, but I don’t think a lot of other agencies out there even know they have a problem. They think everything’s fine. They don’t know about the usefulness of these projects in reducing data collection burden on these entities.
I think we’re still in the realm of needing to talk about these use cases and market them to other regulatory agencies so they can see the benefits of structured data reporting.
Hudson Hollister
Well, your work from the 2006 transformation stands as an example. It has certainly inspired emulators, such as the FERC. I think the time is right for that to continue.
Summarize a few of the projects that have kept you busy in the areas of structured data or data analytics over the last 15 years.
Mark Montoya
There’s a lot!
Obviously, what we’ve done with XBRL hasn’t stopped. When we first implemented back in the early 2000s, they had the formula and we were very vocal on the formula specification, but the specification did not stop evolving. They came out withthe function specification, links repository, and a dimension specification — which I think is great — a lot of big complex statistical forms can be filtered down into smaller reports based on the dimensions. Just recently, they’re working on the open information model, which I think is very interesting in showing the XML specifications moving forward. Then you have XBRL-JSON and XRBL-CSV for ESG (Environmental, Social, and Governance) reporting that’s happening in Europe.
So they haven’t stopped.
Then getting back to semantic, structured reporting, you have the tech specifications and standards that are evolving. Something that’s being discussed now is the Standard Business Reporting Model that the Object Management Group (OMG) is working on. You do have a lot of RDF implementations, you have FIBO (Financial Information Business Objects) that also came out from the EDM Council and OMG.
There are a lot of technologies and standards out there but it’s important to have software that can cut through the complexity so that people can create solutions — like we did with the FDIC, SEC, and FERC. I think that is very important.
The standards keep evolving and the software keeps evolving. I think future solutions will be implemented much faster.
Hudson Hollister
Fantastic.
So far, we’ve been talking about information that private sector companies report to government. Let’s talk for a bit about information that flows from government regulators to the regulated sector. In particular, the text and the structure of regulations that are promulgated by government regulatory agencies.
What do you see as the opportunity to benefit regulators and the regulated by taking the text of regulations, and the meaning, and expressing it in a structured format?
Mark Montoya
That’s a great question. Laws and regulations are complicated. They’re hard to understand. We now have technologies that give us the ability to take those laws, regulations, and policies and put them into a format — whether it be a schema or XML taxonomy — tag them and provide rules behind the scenes.
Laws and regulations are going to be overarching for many entities. Take environmental, social and corporate governance (ESG) reporting, for example. The US Treasury and the Office of Financial Research (OFR) will have their parts. Then the SEC needs to provide some type of guidance for further respondents.
We can use XML and machine-executable technology to define rules for Treasury, OFR, and the SEC to start filtering down to regulated entities to build their solutions. So you have the law and you have the technical file that goes with it, and it helps streamline compliance. It helps the regulated entities deal with complying with these laws and sending that information up to the regulators.
It’s a great time to be in this space right now.
Hudson Hollister
It’s such a big idea and so full of potential, as you describe, and yet hard to start. It’s hard to do this incrementally. Where do you think financial regulators might find the easiest way to start off on such a transformation?
Mark Montoya
It’s like anything else. When you try to do it all at once, those projects often fail. Starting small or doing a proof of concept is a better approach. The Financial Transparency Act is coming up. Perhaps we start with something out of the FTA, and show how a couple of items within the law can be put into a structured format and business rules can be added to help the regulated entity. So again, it starts small and hopefully ends big. I think that unsolicited white papers and proof of concepts will show that this technology will work.
Hudson Hollister
Mark, you have worked in transforming government documents into structured data for longer than almost anybody else. Do you have any personal goals for transformation that you would like to see, or applications for document-to-XML transformations that have already occurred, in the next few years?
Mark Montoya
Yeah. I’ve been at this for a long time. I’d like to see ties into machine learning and AI, of course. I’d like to see how we can actually take the law, put in a structured, machine-readable format, tie it to the regulatory agencies policy, and have that policy then connect down into data systems, and include not just the financial data, but privacy data and cyber data as well. So we’d have this whole lifecycle mapped of where the data is and where it can go, from the cradle to to the grave.
Hudson Hollister
That is very exciting. The comprehensive lifecycle, made automatic at each stage. Well, I’m honored to be able to work on it with you. And I think, through outreach, like what we’re working on with this interview, we can move that feature forward.
Mark Montoya
Yes, definitely. And to the people reading this — we can move forward collaboratively. There’s a relatively small group of people working on this transformation, but it’s got such a big impact and we’ve got such a great group of collaborators. We love to share information as a community, we love to make sure others don’t make the same mistakes that we did, and we will see the future in which this work is fulfilled and helps to make government work better and make better decisions.
Hudson Hollister
Mark, thank you so much for spending some time with us.
Mark Montoya
Thank you.
