FactSet Research Systems Inc. (FDS) Earnings Call Transcript & Summary

Hello, everyone. Thank you for joining today's webcast on digitizing legacy workflows with scalable APIs. Your speakers today are Russell Roeber, Vice President, Content and Technology Specialist at FactSet; and Sebastian Segerstrom, Director within FactSet's Research and Advisory Group. Before we begin, I'd like to cover a few housekeeping items. [Operator Instructions] With that, I'll hand it over to Russell.

Thank you and excited to speak with all of you today. We're going to be discussing right now the integration of API to support the banking workflow. There's going to be 2 main topics that we'll be discussing [ listed ] out here on the first slide in programmatic APIs as well as automation APIs, and I'll be discussing kind of the programmatic portion and handing over to my colleague, Seb, to talk about automation. When we're speaking about programmatic APIs in the context of FactSet Solutions, we're really focusing on delivering the data into the programmatic environments that you're trying to do work, really taking that workflow outside of [ itself ]. The programmatic APIs that we make available allow our clients to extract both FactSet and third-party data via a single flexible endpoint. And we're talking about the Formula API, combining multiple data sets into one or separating that into single content sets that are really hyper focused on optimizing extraction of data such as private company financials, mergers, people, data, et cetera, and then delivering that to you in the environment such as Jupyter Notebooks, our environments, MATLAB, or data visualization tools that will allow you to distribute share reporting and analysis across the firm. I'll pass it over to Seb to discuss, at a high level, how we're delivering automation.

Thank you, Russell. Hi, everyone. So when we're talking about automation, it's really about looking at where in the banker workflow can we drive efficiencies across the board. Really what we're seeing more and more is -- there are a lot of different places where people are spending way too much time doing manual paths that are extremely repetitive and takes a lot of time, effort and energy from the banking community. So what we've done is essentially take our Workstation, look at some of the key functionalities there and do and allow them to be used with APIs outside of the Workstation. So as an example, we have something that we call the FactSet Signals and the FactSet Signals API, which is really leveraging insights and changes in all of the data that FactSet offers today proactively. Taking that API allows you to push that data both in an automation fashion within CRMs, Teams and other type of environments, where you can then leverage that in the day-to-day workflows of banking. Another area where bankers are spending a lot of time is creating report packs and PIBs or Public Information Books. FactSet has an integrated tool within the Workstation, but now this is also available via an API. So again, leveraging the same tools that we've historically had within the Workstation, but allowing programmatic access and automating that process using APIs. What we also want to do is allow clients to replicate terminal access of platform that's why we also have what we call the news and StreetAccount API, allowing you to take the same type of news that you will see within the Workstation and programmatically access that with the same type of search and same functionality that you would have in a Workstation, but with the API. So really adding all of that logic and context on top of just raw news, allows you to take the API and provide automation capabilities, again, across CRMs, Teams and other type of integration points. What we've also done is spent resources creating connectivity with premade connectors as an example within Power Automate from Microsoft and others such as CRM integrations. So with that, we're going to move forward to really giving you an oversight of what we want to focus on in today's presentation. And we've already talked about it, rising need for improved banker efficiency. At the end of the day, it's about increasing deal capacity with finite resources. And what we're hearing more and more from our clients and what we've heard for a long time is that bankers spend too much time on low-value repetitive tasks. So again, we're looking at all of our offering within our Workstation and trying to build that and export that platform with APIs, both so you can leverage it at the same time internally and externally, but also finding a balance between automation and human touch. We, of course, understand that we can't automate away from certain areas of what the bankers are spending their time on, but really finding the perfect balance between is essential. Maintaining high-quality standard library of templates by also giving flexibility to bespoke presentations. That's really what we're focusing on when we talk about improved banker efficiency, and at the same time, being able to create and generate a timely pipeline of ideas, which respond to market events. So it's broad, it's wide, but it's all within the same topic. So I'm going to hand it back over to Russell.

Thanks, Seb. And taking all of those key thematic areas that we would address and solicited feedback and generated this pipeline of APIs and solutions that actually meet those needs for our clients. So FactSet's developed a diverse API ecosystem to address each stage of the pitch life cycle and help to ease those burdens that are mentioned in the banker efficiency in the automation space. Each one of these solutions, from Signals to automation APIs, to programmatic APIs, is meant to address every level of our banking client, from the junior banker to the MD, and ensure that we're delivering the best-in-breed solutions for automation, next best action and advanced data and analysis to drive that efficiency and expand the mandate reach for our banking community. And we'll talk in more detail throughout the presentation how each one of these solutions can fit into an area of that pitch life cycle and deliver actionable insights, advanced analysis, and help those bankers go out, speak with their clients in a very timely manner and deliver that value adds so they can win that deal and do more with less.

So if we look at the pitch life cycle and start within what we define as automation APIs, it's really about what we usually have as a Workstation functionality and not just content. So available for programmatic access via APIs, driving automation or RPA, so robotic process automation workflows, CRMs and more. And really, it's about generating PIBs automatically by the click of a button or even proactively seeing if you're having upcoming meetings and sending you that information pack before that meeting, if it's either 2 hours or 24 hours before, again, that's something that you can set up automatically with automation and sync that with your CRMs. If you need to refresh specific models built in our productivity suite in Excel as well as presentations in PowerPoint, instead of having to update them on the go, maybe you want to have them updated every morning. Again, driving automation in the way that you need and where you need it. Certain models need to be updated every single day. It takes a long time and is causing friction in the day-to-day for the banker. By automating it so updated every morning with fresh data, is just making it seamless to go in and then actually do the value-added work on top. One specific use case that we built out is actually looking at meetings and outlet calendars that triggers notifications into Teams. You can see that at the screen shot at the bottom left. And really there, we're just stitching all the different data points that we have, and we take that into the Microsoft ecosystem, create that Power Automate connector that they offer and create a seamless loop that stitches it all together within the Microsoft ecosystem, within the FactSet ecosystem and helps just drive that automation so that everyone can prepare for meetings and events faster, quicker and more efficient. One thing that we also look at is how can you produce advance data and analytics for prospecting and idea generation and really drive that so that you can phone more clients, come up with more ideas and generate more revenues for your organization. Signals is the other piece. How can we, instead of just providing you with news, served with actionable insights, to make sure that bankers never miss important information and really important data changes about their clients, their prospects and companies that they cover. We also leverage cognitive and AI to use historical data to create predictions or indicators for future events and performance, such as bond predictions, follow-on predictions, index inclusions or exclusions and others. We also partnered with third parties to generate Signals. For example, credit rating changes and ESG data, high-impact news and insights from filings, and of course, we also have regular rules-based signals that flag for changes in companies and user covers. So everything from M&A, financials, activism, supply chain. We have a really bread and butter content. And what we can do on top of that is just highlighting when key things are changing. And that makes the banker more efficient in an automated fashion. I'm now going to hand it over to Russell to speak a bit more about the programmatic APIs and also give you a demo into how that will [ be done ].

Okay, Seb. Yes, to touch on the programmatic APIs here just as we related in, is you see some of these -- some of the bullet points and the topics that we mentioned. We're using -- or clients are using these programmatic APIs to really supplement these workflows of the automation APIs and the signals. When there's a need for advanced analytics or idea generation or charting beyond what's available within the integrated PIB, clients are going to take data from the Formula API, the content API and integrate that directly into those applications or the reports that they're building out for their clients. We see that need when the data goes beyond what's integrated within the Workstation natively. And also when they need to combine raw content with their own proprietary data, whether it be client list meeting notes, any other type of proprietary internal content that would be delivered in FactSet already, could easily be extracted or supplemented with financial content from FactSet, and then used to really supercharge any of those existing automation or pitch life cycle stages that are being pushed out to and meant to help improve and add value to the banker workflow and also remove some of those manual tasks that might have been collated inside of Excel, PowerPoint or SharePoint. And the formal API, as mentioned before, really allows for that because it gives access to all of the data inside of FactSet from that single endpoint. I'll jump right into a more detailed discussion on the Formula API and the content API here before we go into the demo and show you, in real time, how easy it is to actually go in access and generate requests for any type of data that you might be interested in. For those that might not be familiar with FactSet in the data feed space, which is like a generally newer area of interest for our sell-side and banking community, FactSet been in the data feed delivery business for over 20 years. We started with more flat files and less automated solutions, but now have best-in-breed suite of content built around the open API specs to deliver data in the same format that some bankers might be familiar with and if they use Excel or the screening applications that were more Workstation-based. What we've done with our APIs is put them up on a common open website, what we call the FactSet Developer Portal, and they've also created what we call the Request Builder that is a tool and a web page inside of the Developer Portal with typeahead functionality. It will allow even a user that's nontechnical that's never even maybe used an API before, with a couple of typeahead inputs, including company names, whether public or private, the required or desired data items, sales, employee numbers, et cetera. All, like I said, with the typeahead functionality, will allow them to build out an API request in a matter of seconds, generate that with the API key that they might need, and then open that up in a JSON response. And we also have SDKs that are available, so you can integrate those immediately into a C# environment or Python, et cetera. To expand upon a little bit more of the areas where advanced data and analysis are being used to, I guess, programmatic APIs are being used to support advanced data and analytics like I mentioned, it's a lot of the same areas that Seb showed with the pitchbook workflows as well as Signals. Clients are trying to do more with less, and they are also trying to move analysis outside of Excel, where typically our buy-side clients were addressing more academic workflows such as, does a company that issues a dividend or plan to stock buyback, have a positive net impact on their stock performance after that case. Or how do we look at the entire growth technology industry and decide when we should advise our client to IPO. All those types of information may be challenging to wrangle and do inside of Excel and go beyond just more of like a single company analysis that would be available typically in the Workstation. So we're seeing data science and data analytics groups crop up within our banking clients and utilize FactSet's programmatic API solutions and standard data feeds to run that more bulk historical analysis. And they're doing that in Python or SQL, and then moving that analysis into Tableau, Power BI, et cetera and pushing that information out to the banking community. When the bankers are coming to these data analytics teams and saying, Hey, I have a question about XYZ as I prepare for a client meeting, can you help me figure out this analysis, so I can come to the meeting with that advanced level of information that I'm not ready to do on my own or that I'm focused on getting this deal over the line and communicating with the client I need more support from a data-focused team. And that is where FactSet's programmatic APIs really come in and win the day for our clients, and where we're seeing a ton of adoption. And we're also seeing this more on just the more manual side of data entry, especially in the banking community, where CRM is a huge area of interest. Clients are utilizing our data around entities, people M&A, private equity to support the upfront maintenance of their actual entity and contact records, connecting them to the FactSet permanent entity IDs so we don't have to manage all of that on their own. And then when a client or a client internal of the bank or a banker in this case, goes in to select a new entity, we could pre-populate all the key baseline information for those entity and people using FactSet data, whether that be a business description, a company location, a phone number or a website. And the same goes for the contact data. It cleans it up and make sure that when anyone goes into the CRM, that the first contact record that they select is going to be correct. And they don't have to worry about sifting through duplicates or trying to merge together multiple records. It's more manual data tasks that are not value add. And we know that the banking community is faced with a lot of work that's on their plate. And we're looking to remove as much of that as possible and offload all of that data management under FactSet. With that, I'll take a break in the PowerPoint presentation and jump into a quick demo of the Formula API. So when our clients are jumping in, this is the developer portal that I had mentioned. You'll see that there is an entire catalog of content and other information that's sorted here on the [ lock end ] side, they could be filtered down to really target into what you're looking for. When we get the Formula API itself, like I said, this is the single endpoint that allows you to pull data from multiple different FactSet and third-party content sets. We've got a great landing page that discusses the API definition. It gives you a broad overview. You can dive in here to the actual endpoints themselves and start building out right away once you're a little bit more familiar with the process. We'll start with just getting yourself familiar, jumping into the API documentation or available SDK libraries and the notebooks that we've already built out that will get you started on the 15th yard line instead of the first yard line. I'll jump into the Request Builder to just show how easy it is to build out one of these requests for the first time. What I've done is preselected several different private entities. We've got in here Stripe, [ Acomp ] and then SpaceX. Like you said, you can use that typeahead. There's also a more advanced identifier lookup. So we're going to add in SpaceX here and then select private companies. You'll see here I can then select. This is the permanent FactSet entity ID that I referred to earlier. Double-click and okay, and it'll add that identifier here to the bottom. The same goes for adding new data items to the content set, here focusing on private companies. So I'll select net income and then click. Right here you have all of the ability to just do your start and end date. I'm looking for 4 years of information. That all looks good, click enter. And just like that, the new data item is added. I've selected this checkbox that can have a more easy-to-read display name for some of the 3 other items that I've already selected, so a company name, sales figure, employee number, and now I've added a net income. Also, like build requests. And then you'll see here in a matter of seconds, once I click execute, this will open up. I've got -- I'm going to copy over to the clipboard so we've got a little bit of an easier way to do this. Come up and see. Now I've got figures for these 3 different private companies, starting with the name, a sales figure, employee count, net income and then transaction systems architects, the comp for Stripe, same 4 fields, and then I also have the data for SpaceX here. So you could see, honestly, how easy that is. And then flipping that over into a more, let's call it, user-friendly view would be a Jupyter Notebook version of that. Instead of starting from the Request Builder, I dumped this in, import my Panda and Python packages. I'll start with the authorization up here, which is sort of prebuilt in the back end of the Request Builder, and then start bringing in the different endpoints and the requesting information. I'd start by defining the universe of companies that I cared about bringing in, and then pulling in data slowly but surely. Here this is coming from the entity API endpoint. So I want to look at the actual entity structure for Apple, all the private subsidiaries, and then jump in to doing data items as well. So similar workflow. You can see here I'm bringing in the different endpoints specifically, and then displaying them in an object storage manner as opposed to the sort of prebuilt out back-end typeahead functionality. Quite easy, the Jupyter Notebooks are already built out for some of the starting points here. You could see how easy it would be to start swapping in different identifiers, different fields that I care about, tools normally output and integrate these so you can start your analysis. And with that, I will jump back and let Seb speak in on the functional APIs.

Thank you, Russell. That was great. So we talked about signals quickly before. And really, the way we look at it is leveraging proprietary and partner content alongside AI. And really what we're doing is we're taking our expertise and our depth of content and technology to build signals allowing you and the bankers to make smarter, faster decisions. And we are doing them for specific user types. So depending on if you're in M&A or if you're more on the corporate banking side workflow, regardless, we have signals across. And the benefit is you can today consume them in the Workstation, but of course, you can consider buying API. So as I mentioned, we divided it into 3 buckets: cognitive and AI, taking historical data to create predictions or indicators and really just looking at the data to tell us what can happen in the future. Everything from activism to bonds to pricing and follow on, all of those we do predictions for. On the third-party side, really the key insights that are critical to the research workflow. So again, as I mentioned before, credit rating changes from S&P and Moody's, ESG scores and how data actually changed over time as well as key leadership data, people moving in and out of roles as well as rural space, where we take, really, all of our content, but also stitch it together. We can, of course, take our supply chain or sector comparisons, stitch that together with M&A, to give the banker more insight about what's happening, more so than he is telling you that a specific transaction has happened. We cover over 30,000 public companies and over 3,000 PE firms together with all their underlying funds and portfolio companies, allowing you to make any type of research and any type of insights proactively across both public and private markets. Let's jump into a few different examples that I can show how you can make and do faster decisions and drive efficiencies as well as more revenues for your firms. So as an example, for our coverage team, a person is moving in or out of the role allows you to win new business, right? Monitor personnel movements among existing relationships and reach out to potentially win that new business through that existing relationship. For your financial sponsors team, we can actually look at the average holding period of every firm and every fund and telling you which PE firms or which PE funds are reaching the end of life and could potentially be seeking exit, allowing you to find potential transactions and being able to pitch them. For M&A teams knowing about not only the transactions that are happening, but also monitoring once they've been announced, if they're actually happening. If there are rivaling bids, if they're trading significantly below the actual bid that was put in, so you can evaluate deals in the market that are at risk or base prolonged closing times from competing bids, shareholder activism, or of course, arbitrage or market speculation. What you can do in the restructuring and DCM teams is if bonds are maturing within a certain set time, generate opportunities. For example, automate that automatically in sales force dynamics or other type of CRM environments, and you can leverage both our bond and loan exploration signals in those type of environments to really drive the learning mechanism to reach out proactively before they actually need to have new type of debt set up in order to really get those efficiencies and drive that in an automated fashion. Next, we're going to talk about what we define as the BookBuilder tool. And really what that is, is a way to create Public Information Books or custom report packs really for meeting prep or giving you an insight into a specific company. So think of it as all the different data sets, all the different reports that are available within FactSet, you can create presentation-ready report packs out of those, leveraging all of our content, but also all of our reports in an easy-to-use application that is accessible in the Workstation, but now also via API. What you get is presentation-ready PDFs, so you get title pages, table of contents, as well as divider pages. But you can also, of course, schedule a batch and the opportunities are endless when you instead use our API so you can do custom report templates, you can also save them for regular use, and of course, send these books in any shape or form that you like. And really, what we're seeing here again is this is something that bankers has done manually for ages. But again, it's about stitching a bunch of data together and spending a lot of time doing that in connection between more junior and more senior people across the firm. Doing that automatically via an API makes so much sense from multiple angles. And that's really how we want to be able to showcase today how you can stitch that together. Building connected ecosystems is the way we do that. So what we could do with our Signals API and our BookBuilder API, together with our cognitive services, is that we can extract the company, a person or a location name from the text of a document or for example, an invite in your Outlook. And then automatically see that, oh, you're meeting with X company, generate a book and the key signals that I care about, depending on what type of role I have, and push all of that information directly into Teams. So what we're leveraging is really the ecosystem of Microsoft, Power Automate, Teams and the FactSet API as a content, all together. So when an upcoming event is starting, grab the entities, from example, subject, e-mails, et cetera, grab the book, get the events they care about, create the file, and then post that adaptive card into Teams. Of course you can do this in any type of environment, but here's showing you how quickly you can actually leverage all of these tools together in a single workflow is so, so powerful. I want to end with talking about our news API. So really, it's about accessing our rich Workstation experience by an API. So think of it, of all the functionality that we've already built into the Workstation, that is now built into the API with different endpoints and different type of functionality. We've also added our unique StreetAccount service written by financial industry professionals to filter out noise to instead give real-time news in bullet point format to save even more time. So we think of it as an API with news that gives you enriched content, which is reference links to the actual source of the document, metadata as well as tagging you can save the specific searches, but pull them out of the Workstation and of course, personalized. So it's really about the differentiating pieces of personalization in large scale and full into linking into the FactSet ecosystem because another thing we're hearing a lot with clients is that they want one source of truth. You shouldn't see different types of things depending on your -- within the terminal or outside. It should be one experience that is seamless across inside and outside, for example, the FactSet ecosystem, but also your CRM, et cetera. So what we really now talk about is our strategic areas of focus for banking. It's about equipping tomorrow's analyst that has coding knowledge and want to leverage the Formula API that Russell talked about. It's about delivering essential content. And also, we want to facilitate an open partnership. So we want to partner with Microsoft, we want to partner with our clients, and really drive key delivery mechanisms together with functionality through APIs and really, that's how we think about it. These 3 different pillars, all stitching together, our Workstation, our off-platform capabilities via API, into one single ecosystem. So many think of FactSet as a content partner. But really, the way we look at ourselves for the sell side is a content partner, a workflow partner as well as a technology partner. So we take all of that content as well as all of that technology and expertise that we have and serve as the trusted partner for banks. We want to collaborate innovate and grow in lockstep with our clients. Thank you so much for taking the time to listen, and we're now opening up for questions to both myself and Russell.

Thank you, Russell and Seb. Let's dive into some of the questions we received. The first one is, what is the difference between a programmatic API and a standard data feed?

Sure. Thank you. It's a great question. So as I've mentioned, FactSet has been in the off-platform data delivery business for over 20 years. And we did start with more like the both data feed approach, where our clients are looking to basically maintain a copy of an entire FactSet data set like fundamentals for financials on their side in a more SQL-based environment. And that's great. It really helps with doing deep historical analysis, having broad access to all data items and securities in a given universe. But there's also a need for clients to utilize APIs for the ease of not having to maintain a SQL database. And also call-in content on more of an ad hoc basis. APIs are a great scalable way to get access to FactSet content without having to pay for and maintain all of the infrastructure, but an entire standard data feed would allow for. The other advantage of the programmatic API is that you could just easily use that typeahead of functionality that was shown in the Request Builder and get a similar-looking deal that our banking community has been familiar with as the Excel functionality as the first starting point without having to learn SQL, which could be a larger task that most people may not be interested in. So just trying to build out [ some ] Jupyter Notebook.

Great. The next question is, are the functional APIs interconnected with the Workstation in any way? Are they production use or individual use?

So to answer the first question, yes, these functional APIs are actually connected. So you can leverage your specific Workstation and really build off of that with all your settings in an off-platform environment. That means that, for example, the PIB creation that we talked about before, you can actually do some of the manual steps within the actual Workstation, but then leverage that outside of the Workstation with the API. So they are interconnected. Same way if you have a new search that you want to save within the Workstation, you can then leverage the API and pull that data off-platform. So yes, they are interconnected in that sense. One thing that we do really well is it doesn't matter if it's individual or if it's actually a production use case. You can still leverage all of that functionality within the Workstation even in a production use case. So we're open and flexible in the sense of if you want to build it individually where we see that some bankers really just want to take all of our APIs and run with it and build these type of workflows themselves, while others just want to have a single production use case that still powers all of the different bankers and their workflows and generating the data and the output from the API that way. So both, really, for the second question.

Thank you. Next question is how do you track usage of the APIs?

I can take the first step of that. So on the programmatic APIs front for pulling content within that same developer portal that I opened and showed for the Request Builder and accessing from the API, there's a drop-down that allows clients to go down and view usage on a monthly basis. The key metric that we use to track usage is data items or data points. And that is a focus on really a throughput of content that's being delivered by FactSet via a given API endpoint, whether that be the formula time series or cross-sectional or one of the content API end points. Clients are able to see for the month of February, how many data points have they requested, the number of requests, and all of that will go into the licensing and contracting conversation that happens after a client trials the service. So they can monitor, hey, how am I tracking on usage relative to my license? Do I need to have a conversation with FactSet about increasing that usage based on the fact that we're building out a lot more reports and getting a lot more great usage on data and we have these leads that are expanding? But it's all upfront and available for you in real time to track without having to interact with anyone on FactSet's side.

So for the functional API, it really depends on the workflow. We have certain use cases where it's an all-you-can-eat model. So you can really call us as much content as you need. We also have the ability to limit, so that automatically when you reach a certain threshold, you can't pull more information. And then, of course, we can provide you with stats of the number of post, the frequency, et cetera. So all of the data that is being pulled in the API can, of course, be presented and give you information about how it's being used and frequency of pulls as well as size of requests.

Great. Another question we have here is, do you offer assistance in implementing or leveraging these functional APIs, such as integration into Teams?

So we actually have an automation team in-house within FactSet. So if you're looking to automate processes, we can work together with our automation team to really make sure that you're leveraging all of the functionality that we have built into the API. And again, it's about that partnering with our clients. So really, what we want to do is understand the specific use cases and where it's being used and provide advice as well as helping in how we can build out specific tools for that. As an example, we already have a connector available in Power Automate, which automatically then plugs into Microsoft teams so that is already available today through the Microsoft ecosystem. But of course, we can help with any custom setups as well together with our automation team in-house.

Okay. And this last one looks similar to one of the first questions responded, but in case you want to just confirm this, do I need Workstation access to use the Formula API?

Sure. Thank you. It's a good question. And similar to Seb's description on individual versus production, yes, it sort of depends. So we have versions of the Formula API that are meant for just a single user. We call that individual use case. And that's for the banker that's looking to just move outside of their cell workflow for running models and generating and pulling data. That can be tacked on and added to mirror your Workstation access and comes generally at a lower price point. We also have production access to the Formula API that does not have any dependency on a Workstation and can be set up for access to an entire data and analytics group, whether that's 5, 10, 20 individual users. So it does depend. But if there are situations where you have technical users or data analytics group that doesn't have a need like a banker would for a FactSet Workstation, you do not need to have that in place to access the full data via the APIs.

Okay. Thank you both for your responses. If we weren't able to get to your questions today, we'll be sure to follow up with you as soon as possible, but this concludes today's event. Thank you for joining, and enjoy the rest of your day.

Thank you very much, everyone.

Thanks, everyone. Take care.