Cursor for Financial Services

0:00 All right. Um, we can get started. Hi everyone. Um, my name is David Sha. I'm a on the cursor enterprise team and yeah, look forward to kind of covering cursor for financial services today. I know a lot of us have sent across um specific questions. So, you know, I think aim today is um we'll we'll walk through a good healthy dose of of cursor for financial services and kind of cover as many questions as we can. Uh, let me pass it to Hugo who will kind of take

0:28 point for the session. Thank you. Uh nice to meet you all. I'm Hugo from the field engineering team here at Kurser. Really in charge of like scaling best practices across uh agentic systems and especially working with our financial services organizations who are our customers and soon to be customers.

0:43 Really excited to be presenting today. As Davis said, we're going to be going over a number of topics. Uh really focusing on like how do our customers use us today in production. Uh what are some best practices? Uh what's our security posture? than going to more of like a non hands-on demo as to how to use cursor in a secure and compliant way. Uh so the first piece is just like kind of like level setting on cursor usage you know across the industry

1:07 today. We are seeing about 64% in the fortune 500 uh using cursor. Uh we're very lucky to have a lot of coverage across some pretty incredible organizations including uh some like Nvidia. I know Jensen Hong saying that we have about 40,000 engineers at Nvidia using cursor every day. Uh beyond that, specifically in financial services, we're seeing a lot of traction and we're seeing customers adopting cursor across a wide variety of sub subsegments

1:33 including banking, asset management, capital markets, fintech, wealth management, insurance, and payment processing. So, lots of interesting use cases that we're seeing uh things that we have never seen before. They're actually very fascinating that we'd love to [clears throat] share with you. Our ambition in general is to really try to build a fullyfledged AI platform wall-to-wall that covers all aspect of the SLC. And so with that in mind, just

1:57 kind of level setting as well on what our product surface is today. We really started out with a cursor desktop application, essentially a fork of VS Code. Uh we are very far away from VS Code today. really trying to move into less of an ed editor-based model and more so like a agent-based approach where agents are the center primitive of the user experience for developers to use. And as part of this uh platform as well is really this idea of building

2:25 product primitives for every single use case so that you're able to use cursor across the entire life cycle and very much polishing those handoffs. So being able to use things like bugbot for example for coderview and things like CLI command line interface for more headless uh CI/CD use cases. This is complemented by a very robust context management approach. So essentially being able to use things like semantic search and a dynamic context discovery

2:50 across very large code bases. We were seeing a lot of success with those um use cases for cobalt for example cobalt migrations being able to use semantic search to understand the current state which wasn't necessarily fully understood and then from there migrating to a newer stack and then finally on top of this really focusing on the model intelligence piece uh we uh pride ourselves in having some very good partnerships with all the large model

3:13 providers openai google anthropic xai and beyond this also building our own internal knowhow as to specialize machine learning models that are purpose-built for the coding use case like composer one. uh beyond this you know in terms of covering the SDLC really thinking about not just the uh very visible and very RAI heavy uh development use case so purely code generation but beyond that looking at other use cases like code review for example which is becoming uh soon enough the biggest bottleneck today

3:44 as we're generating more code how do we securely and reliably verify and vet that code before it goes into production uh and part of this is testing and QA we've recently acquired graphite a code review company so we're really excited about the opportunity there. And beyond that, covering every piece both upstream and downstream, including things like planning and design, but also QA, deployment, monitoring, being able to have the agent kind of self-drive a lot

4:08 of these actions across various systems so that you can bring the maximum amount of context possible and make your code more reliable. in practice uh in terms of common use cases. So we're seeing everything from rapid prototyping within uh banking to larger migration refactors across more critical infrastructure like mainframes or you know transaction processing uh everything from microservices to more modern frontends for institutional banking uh testing and QA. Obviously, a lot of this effort is also focused on

4:39 industrializing your testing infrastructure with agents so that code can be more reliably reviewed and also so that you can clear the backlog of juror tickets that you're handling today when it comes to modernizing your stack right uh and then beyond that looking into more specialized use cases things like data science thinking about how do I use cursor for uh building new models for machine learning pipelines how do you use cursor for ML ops for uh

5:03 building uh you know training strategies And finally, DevOps being able to use cursor across, you know, again, all kinds of services, including the CLI to be able to build your own agents uh in your own CI/CD pipelines in GitLab, for example, uh using JROG, all those systems.

5:21 In terms of enterprise controls and tools, uh we've been doing a lot of work on this end to really make sure that our security posture uh fits the needs of the most stringent u you know, institutions, financial institutions. We work with a lot of government adjacent and very regulated industries uh across you know banking, asset management, hedge funds, insurance businesses. Uh really thinking about two things. The first one is really deterministic

5:45 controls. So what you're seeing right now being able to deterministically say the agent is able to do this or it's able to not do this with things like hooks and sandboxing. Being able to decide what commands or MCPs you can run and allow listings or models because you find them safer for usage. Uh we of course uh support reserve data retention out of the box with something called privacy mode. We enforce privacy mode for all of our enterprise customers. So

6:10 no no training on the source code and no training either from our third party model providers and we enforce this through legal guarantees with zero data protection agreements. And then finally more standard things like of course data cryption at rest and transit uh soft 2 type2 certifications and uh global compliance standards like GPRCPA and then the second piece of this in the security world is how do we actually use more probabilistic processes to steer

6:38 the models towards better outcomes and that's when typically things like skills and MCPS come in but also sub agents. So both being able to give capabilities, integrations to your agents to integrate with your existing SDLC toolkits as part of your institution, but also using sub agents to perform more specialized jobs that are typical of more regulated topics like for example compliance, PII scanning, data loss prevention, uh scanning for vulnerabilities, etc.

7:05 really boiling down to integrating uh deterministic and probabilistic processes throughout the entire life cycle. So as opposed to generating a huge volume of code and then having the human be the bottleneck and then having to review all this with absolutely no regard whatsoever for compliance weaving in all of your existing security tools and deterministic toolkits directly into your existing agent pipeline here legacy code being refactors becomes AI code. AI

7:31 code gets reviewed and goes through your security and compliance process that the agent drives with your existing tools and then back into your pipeline here into your policy engine and CI being able to reliably check for any issues and then into production. [clears throat] All right, now moving on more to the topic of adoption. We've heard a lot about how do I adopt AI? How do I make sure that my my team is adopting agents the right way? How do I actually measure success and RAI? Well, we're seeing a

7:58 lot of these orgs thinking about this broader AI maturity curve uh and thinking about where they're at in this specific cycle. So, really starting from prompting blocks of code about a year or two ago, focusing on AI as a pair programmer and really small scope tasks like file edits, moving more towards guided feature generation and towards more so autonomous development. We're around here. So really this idea that we're able to build entire applications

8:23 from scratch with cursor and also focus on very deep and complex engineering projects that span thousands hundreds of thousands of files. So something like AI as a junior engineer and also AI as an engineering team. If you look at more of this in terms of a matrix we're starting from devs not using AI so very manual and very synchronous uh moving towards dev using things like autocomplete cursor tab which was our original product. So a little bit more synchronous, a little bit more autonomous. And then cursor

8:53 agent, moving towards an agent-driven experience within the ID. And finally, moving towards something a little bit more advanced, multi- aent orchestration, much more autonomous, much more asynchronous, less focused on the code itself, focused more on this idea of orchestrating multiple agents together as part of a broader agentic team. And that's where we're seeing the future state going with things like sub agents, delegation, uh having, you know,

9:18 sub agents each perform their own job depending on the use case. Uh we're really building ahead of that future, especially with this new 2.5 release that is coming up. All right. And then in terms of how we measure the success, we actually uh accompany enterprises through the process of trial and cursor with the free 30-day trial. And we really try to uh help you along the entire way with very purpose-built enablement around you know cursor initial agentic features and then more advanced topics like agents

9:48 skills context management primitives larger factors and projects and then we help you measure this through our APIs with built-in analytics. So being able to measure uh how people are using cursor if they're accepting the changes how how much of this code is AI generated and how much of this code stays in production when it's AI generated to measure its quality and then beyond that more uh specific topics like growing a group of power users that

10:12 are driving adoption internally uh helping you also uh unlock you know a a curve in terms of increasing task complexity tackling more and more complex tasks delegating more thinking in systems and being able to delegate your systems thinking to agents as opposed to babysitting each agent individually. Those are all topics that we cover that we help enterprises with at scale. And this is typically what we did when we um essentially work with Nvidia with their 20,000 engineers across the whole whole company to

10:42 implement cursor. And this is typically what an enterprise dashboard would look like for your team. being able to track all these analytics in one place and even being able to tie them back to product life cycle metrics beyond just the quantitative piece. All right, I'm going to pause here maybe for any questions and then uh going to move into a demo.

11:04 You go, there's one question um just as we head into the demo. Can you make cursor use a Chromium browser, let's say Brave instead of Chrome to directly perform tests on web app pages? >> Yeah, that's a good question. So we do have a built-in chromium. Uh keep in mind that you can use MCP to connect to external browsers. So if you think there's an MCP that would be a good fit for this. So if you just want to use player right directly, uh that's totally

11:26 possible and it could be agent driven. All right. Um if there's no other questions, I'm going to switch to demo and always address some of those questions in chat if I have time. Let me switch to the demo portion. So here I have this example codebase that is really focused on building essentially a stock tracking dashboard. So I built this from scratch using cursor. I'm using index.js front end and I'm using a convex database in the back end. So this is a full stack application. Now it

12:00 turns out that in this use case I actually want to add a new feature and there's a lot of existing context that's built into this. It's not something that I can just displace uh from the get- go. So the idea here is that I actually have a PRD that is located in Confluence that my product manager has built and I want this PRD to be surfaceable in cursor and start building on top of it. The idea is that within this stock dashboard I want to uh create essentially a feature that

12:27 allows me to track suspicious activity reports and automate them uh and surfacing them within the user flow. So there's certain number of criteria here in terms of functional requirements transaction detail trigger uh generating AI narrative risk factor detection compliance controls etc. There's a number of data requirements from the back end that we're also surfacing and some success metrics and so this is all in conflence. Now the first thing I want

12:52 to do as an engineer here is I actually want to go back here and obtain this specific prd from conflence. Now, one of the things I'm going to do here is with an MCP, specifically the Elastian MCP, that I'm going to restart here. I'm able to pull this PRD automatically from Alastian from Confluence. So, one of the big topics here is whenever you are in a large organization that is using a lot of these vendors, uh some of these vendors will have MCPS out of the box

13:17 for APIs or CLIs and those are things that can be leveraged automatically by the agent including the Elastian MCP. And so this really helps with essentially u equipping your engineers within cursor with the ability to avoid context switching by bringing context and writing context back to those systems directly within cursor. Notice how I'm using uh the MCP here to pull the PRD directly in here and it's now in context for the agent to use directly.

13:46 >> Hey you go. One question popped up. How to get the PRD templates? >> Uh so this template is something I I built myself. I didn't really use a template. Uh keep in mind that you can just integrate this with your existing product process. So if there's like a process you use currently for for product if it's using a PRD, if it's using spectrum development, if it's pulling artifacts from Jura tickets, uh those all work. It's just a matter of like which connector you're using and what your workflow is. In this case, I'm

14:11 just pulling a simple PR from Confluence. Notice I'm using cloud 4.5 Sona here. you have the ability to switch between different models and you can use of course either anthropic models or Google or bini and you can even switch your own internal model composer one. Now, in this case, what I'm going to do once I pulled this in now that the agent has context over it, I'm going to switch to plan mode and then say write a plan.

14:37 And I'm going to use claude 4.5 opus for this one because it's a high reasoning task that requires a lot more uh effort. And so I want to be uh really like focused on the architecture and the systems design approach. Now, one of the things I actually built before this demo was something called a skill. So let me actually switch places here. A skill and this skill is uh the ability for me to give capabilities to the agent. Notice how the agent here is

15:07 using sub aents to perform some of the work. And so actually what it's doing is it's leveraging this skill that tells it to scan different parts of the codebase for the current state. So things like uh analyzing the schema in my DB, scanning components, mapping the API surface, finding patterns, and then uh gathering uh my architecture into a comprehensive plan. Those are all things that you can encode yourself and that you can map directly to your process internally at

15:34 your company. And so if it's focused maybe on more so architectural planning, you can totally change the skill to map that process. So we now have a plan. Uh this plan goes over all the different architectural topics. It's gone through my skills. So it's mapped exactly to the way I do things currently in my company and it goes over uh the actual components install, what to do in the back end, how to extend it, uh how to generate these like components, etc.,

16:04 etc. This plan is of course editable. I can change it however I want. I can edit it. These 2DS can be edited. I can even ask it to write the test for me or even rewrite the play entirely to follow a different direction if there's a fundamental misalignment. >> Hey, Hugo, there's a couple common questions around like when would you use a skill versus just adding a command into your prompt or a rule. >> Yeah. So, the uh the beauty of skills is that they're automatically invoked. You'll see here that uh essentially this

16:32 skill was automatically invoked by uh my agent and it was able to understand to use it. So this is really useful because again if you specify when it must be used it'll be automatically mapped to that task as opposed to having to manually invoke it. Uh skills are a bit the next evolution of rules and commands. They're both invocable manually and invoked automatically by the agent depending on the context. >> And how did it know uh which purity to

16:55 fetch? Is it connecting using an MCP for confluence or >> those are all things you can define directly. uh you can essentially define this in text directly in the skill and say use the MCP to do this or that and it will be able to leverage it if that MCP is activated. So it's really just all uh natural language prompting in files that are then automatically pulled by the LM.

17:19 All right. And from there I can go forward with actually building this out. So because this plan is already kind of built out uh there's not much more to do here in terms of reasoning except maybe uh you know rewriting a little bit but otherwise looks pretty good. I can use composer one our internal model which is very fast in terms of inference to actually build this out. Going to click on build and it's go through the process of like looking at all these todos and

17:44 then building them one by one. And so where this is useful is composer one is very good for uh high velocity pair programming. You can see how fast it flies through things. Most of the reasoning has happened in the planning phase anyways. So, it's actually good for me to fill faster and to get that result immediately. And that way, if there's any issues, I'm able to interactively change the direction with composure one.

18:09 And so, you can see how efficient is implementing this plan that was generated using cloud 4.5 opus. I'm going into uh specific aspects that I added to this application. I separately have a rule here that I defined. This rule says when writing plans, always include a testing strategy for both unit testing and integration testing. And if you go back in the plan, you'll notice that I was in fact adding a testing strategy for both unit test integration tests. So my role was properly followed which means I can

18:39 standardize all my testing practices and plan writing practices across the entire organization because these things were shared for everybody. And so that's really useful again for making sure my agent is reliable and compliant with all my SCLC practices.

18:55 Sub agents are also very powerful going back to the sub aents that were used here because they will break down the tasks in their own context thread. Notice how here I had this sub agent before planning. And I was able to explore my entire backend, all my APIs, all my data primitives here and then surface my full uh data structure to the main agent to then inform the plan. So everything is built in the context of the current state with semantic search

19:22 plus sub agents each performing their own role to gather context about the data models to gather context about the actual UI and to gather context about uh the structure of the application. Let's go back here. It looks like everything is fully built up. We are essentially good to go. And you can see how my transactions appear here. And I can open this. Now, there are still some issues. So, I can fix that directly using my verify aspect. So, I have this

19:48 >> Hey, you go. There's a Oh, sorry, didn't mean to interrupt. There was a couple questions on how do you create a sub agent, invoke sub agents. >> Yeah. So, sub agents can be created directly in the agents folder here. Now, one of the advantages here is I have a a command that allows me to run this. So, let's see. I have agent. I'm going to switch to GPT 5.2 codeex and I'm going to say verify all changes. Now the idea there is that when I verify

20:13 this uh it will be able to invoke the sub agents that I've defined. So here you'll see it says reading skill verification details learning verify changes. I've built a skill called verify changes. This skill invokes sub agents. It says whenever the user asks me to verify my changes, I want you to invoke all these subvisions that have been defined elsewhere. They're defined over here. I want you to invoke PII compliance checker here. I want you to invoke security scanner verifier and

20:46 testrunner. And so if you look at the individual sub aent definitions here in the doc cursor/ aents folder, they each have their own job. PII compliance checker is a sub aent running a different model composed of one much faster that handles checking for PII issues. Security scanner is a different sub aent that runs claude 4.5 sonnet that actually runs the sneak MCP to check for any code issues. So this is deterministic. We're not doing anything

21:15 proalistic. We're literally running our existing pipeline in sneak to check for any issues and that's running in a sub agent that I've defined in text. And then finally looking at testr runner. This one is built for running tests. So it's really focused on running my entire test suite and checking for any issues.

21:34 PII here checked for any issues on the PII side. It looks like there were actually some risks, data leaks and other issues. Uh so I should definitely check that out. But overall I get this kind of workflow where by just saying verify all changes. I each have their sub agent running their own job with their own compliance task perhaps with additional MCPs and help from the outside and we can map our entire banking SDLC process to these sub aents and skills and then execute them in one go and everybody is working out the same

22:02 base. Reason why I chose 5.2 Codex here is because 5.2 Codeex is an excellent model at long horizon code review tasks. So, it's really excellent at being able to invoke those specialized sub aents and then a report back with a summary. Notice how after running all these sub aents, it was able to give me a status for each of these. PI PII doesn't look very good. Security looks good. Sneak did pass with no issues. Implementation, it looks like there was an issue with my verifier and all my tests passed. So,

22:33 this is actually not too bad and we're in a good state. Ready to commit? No. Uh, let's move into fixing these issues. So you can imagine how we could go move forward with this and go go into a broader uh review process uh simply by clicking on review looking at the code changes and then even running an automatic uh review process by clicking on find issues no problems and we're good to go. So again, you can repeat this loop over and over.

22:58 You can make it more complex, map it back to external tools like Sneak, GitLab, Jrog, Artifact, whatever makes the most sense, and then encode these as sub agents and primitives that you can reuse across your entire team. That way, everybody is working off the same uh base and off the same kind of agents.

23:17 I'm going to pause here and we're going to take some questions that we have five minutes left. >> Here you go. If I were to batch up a few questions, there's there's a few around the topic around uh integrations with more legacy mainframes, cobalt, SAS. Um could you talk a little bit about how cursor could apply to those use cases? >> Yes, so we've had a customer larger stock exchange who is uh looking at potentially you know using uh cursor to help with cobalt mainfree migrations. We have had this for a few customers. The

23:46 way this works that essentially you can leverage the cursor CLI to work with cursor in headless environments. So to give you an example here, let me just close all my tabs. And then I'm going to open this in full screen and then open this in a new tab. And I can use those same agent capabilities as the IDE directly in my CLI. And so we see a lot of teams who are essentially using the cursor CLI with those same exact ID capabilities within a headless

24:13 environment within for example a you know bastion host system that then uh makes changes to uh your cobalt mainframe uh in an actual EC2 container in a docker container uh in a remote VM whatever makes the most sense you can run cursor wherever you want and have it directly running as a CLI headlessly or interactively.

24:39 I'm going to answer some of these questions that are in chat. Um, is there a golden rule which should be so there's a few questions that are a bit similar here. Uh, difference between sub agents and skills. So, essentially a lot of these are interchangeable. The idea behind sub agents is that it's meant to be a job for an agent to execute and sub agents can be executed whenever, right?

24:58 Depending on the context. Skills are really meant as capabilities that you're adding to the agent. Now, one pattern that is pretty cool is like I did here, use a skill to define what capabilities the agent has, including which sub agents it should execute depending on the context. And that's where it get it gets very powerful because by just saying verify all changes, I'm able to have this skill trigger and then execute all those sub agents. So, think of it as

25:22 like more like an orchestration layer. Again, these are all interchangeable. There's no hard or fast rule. depends on your workflow. Uh you can invoke cursor agents from Google cloud remote machines the same way you would do it from EC2 in AWS. So it just depends on how you're doing it. Uh you can use our CLI headlessly and not interactively to do this.

25:42 Planning execution is not limited to one repo. You can do this in parallel. Uh here I use one agent with multiple sub aents. I can run agents in parallel to do other things. For example, deep code review of the codebase. This could be one agent and then I can run another agent that itself is focused on planning with a different model. For example, write a plan to improve uh accessibility. And you can see here how I have two different agents running in parallel. One is planning, one is making changes.

26:12 I can have another one asking. Uh there's really no limit there. And you can even run them in separate work trees to separate changes and make them logically separated. Uh it's not overkill to have more than one MD file. That's totally uh fine. It's actually a recommended pattern to segregate your topics and your sub aents and skills depending on what you're trying to do, depending on the use case. Any plans for marketplace? Yes, that is coming soon. Uh we are going to be able to package um all these different topics

26:39 and hedge against you know the risk of having to switch every day between like these different standards into plugins and you'll be able to pull plugins directly from the cursor marketplace. So this is coming and I highly recommend that you check it out once it releases because it will be uh very appropriate for enterprise customers. Agents MD are a bit dated in the sense that they're not as capable on like uh being able to describe when to invoke certain topics.

27:02 They're more so uh just like static context that you added to the context window. So prefer for that. >> Uh you go there's a oh sorry there was a webinar question around can we integrate bugbot into the code before code checkin like a plugin or extension? Uh you can totally do this in the ID.

27:19 Yes, you could potentially have a whole review process in the ID uh either natively through a review process through your agent review or separately with an MCP before it even goes to a bugbot in CI. Totally possible. U coming back to those questions on PRDS uh when you look at you know planning and these plans uh some people call it a spec functional requirements document PRD depending on high level or lower level.

27:45 It's all kind of the same. We don't distinguish. Uh it's up to you depending on your workflow and how you want to build things. Some teams are much more spec development than others. Some of them much more focused on product. These are all the same. These can all fit into a plan. Plan is meant to be agnostic.

28:01 >> There are a bunch of questions around model selection especially with respect to agents and sub agents. Um how to know which one's best for which? Um I think you confirmed earlier it's configurable at the sub aent level. >> Yes, that's correct. So we have a lot of like different uh ideas about this. Let me just share my screen here. If you look at uh wider model selection practices, a lot of it will depend on specifically what you're trying to

28:26 achieve, right? So if you're in a research and planning phase, use a uh model that is really good at u you know planning. So for example, composer one for interactive planning, faster, more efficient GPT 5.2 codec for deeper investigations for sub aents depending on the task at hand. Also, if it's longer horizon versus shorter horizon, use GPD 5.2 codecs for longer horizon 4.5 Opus for planning medium horizon and composer one for execution. Finally, for

28:55 reviewing, debugging and verifying, you might want to use a GPT 5.2 CEX, but that again totally depends on the use case. These are typically topics that we cover with our enterprise customers as part of a a trial. >> Awesome. Thanks, Hugo. I know we're wrapping up on time. Um there are a lot of questions around sharing the presentation and making it available. So we will be sending a follow-up email um with the slides from today. Um I think Hugo there was a popular request for your MD file and um so we'll we'll we'll

29:23 send across all that and there were a lot of questions around aentic coding. So just a heads up um in our upcoming two workshops we'll have a cursor for security team session and a cursor for aentic coding at scale. So definitely highly recommend given um a lot of questions around those two topics today uh to check those out.

29:44 >> Thanks a lot. Appreciate it everyone. >> Thank you so much. Take care. Bye-bye.