Nori Agentic：利用云端 Agent 重构金融证券主数据与后台数据核验

to be here on stage at AIE New York.

This is kind of awesome. Um today we're

going to talk a little bit about the

Agentech SecMaster. But before I dive

into things like introductions, I want

to talk about something that's been on

my mind recently, especially as I was

preparing for this talk, which is

finance has gotten kind of weird, right?

Like when I was growing up, finance

mostly meant public markets, you know,

trading floors, ringing bells, things

like that. And that's not really what

happens anymore. There has been a huge

influx of capital investment into

private assets. And some of these

numbers are kind of staggering to me.

Apparently last year, there were $240

billion of secondaries volume in 2025,

which is up 50% from 2024. I'm sure in

2026 it's even more than that. And

people are now forecasting that we're

going to do $32 trillion of alternative

assets under management by 2030, which

is only 3 years away.

Now, why is that happening? Why is this

the big story in the finance world?

Well, some of this is because AI seems

to increasingly be the only growth area

in the broader economy. So more and more

people are holding on to and investing

into all of the things that feed the AI

world. That's land, energy, data

centers, GPU clusters. And of course

secondaries, right? Everybody is holding

on to OpenAI and Anthropic secondaries.

They're everywhere. All of these private

AI companies, everybody's trying to get

a hold of them.

But it's not just an AI story. Some of

this is also a regulation story and a

story about seeking alpha.

High growth companies are finding less

and less reasons to go public. They

would rather just raise a series F. More

control for the founders, less paperwork

to do with the government. And if there

are these massive well-funded firms that

are taking over and squeezing the juice

out of public markets, well, you're just

going to start looking for edge

somewhere else.

As with all things, I think Matt Levine

said it best. He actually wrote this a

year ago. Private investment firms have

become huge, and the legal distinctions

between public and private markets have

become way less important. If an

increasing share of the economy is in

private assets, investors aren't able to

just index. You can't get the market

return by buying every public stock if

half of the market is actually in

private companies. So, you end up with

this cycle. There's more investment in

private assets, which means more people

have to invest in private assets just to

make sure that they're getting the

returns from the wider market.

Now, one thing that's really frustrating

is dealing with private assets. It's

actually really, really hard. How do you

manage private assets? How do you keep

track of things like how many shares you

own or what your strike price is? I

mean, I'm a startup founder, and I find

that frustrating just for my own little

bit of stock. And if you invest in a

plot of land next to a hydro plant,

things get really weird. Where is all of

the information about how much you paid

and what your rights are?

Well, unfortunately, it's in PDFs. It's

in a box folder or in an Outlook email.

It's in a Zoom call transcript.

Sometimes, it's on a napkin with a

hastily scribbled signature from a bar

overlooking Columbus Circle.

Welcome to the nightmare world that is

managing private asset data, something

that more and more people in this room

and in New York in general have been

dealing with over the last couple of

years.

My name is Amol Kapoor. I am the CEO of

a company called Noriagentech. We build

cloud agents, and today we're going to

talk about how you can use cloud agents

and AI in general to make it easier to

manage, record, and audit a company's

investments. In particular, a company's

security master database. Now, my

background is actually in AI. I've been

an AI engineer for about 12 years. Uh

four and a half of those years were at

Google. So, funny enough, I am not the

best person to actually talk about what

a sec master is. But, I'm very lucky to

be joined by my CTO and co-founder

Cliff, who actually has spent some time

in back office finance here to talk to

us a little bit about what a sec master

is before we dive into how AI can solve

those problems.

we

before we talk about where this is a

hard problem, I think we should get a

lay of the land. We can talk about a

simpler example with public equities,

then we can tackle some of the

complexity that comes with private

assets.

So, every asset manager right now

currently runs on a sec master.

So, let's define that.

Asset managers need to know what exists

in their investment universe or in their

tradeable universe.

This is a critical piece of back office,

brings together engineering, operations,

and data.

You can think of this as just a master

database of all securities or

instruments that represent the assets

they're holding.

For the engineers, you can think about

this like any master database, it's the

source of truth, and usually the

starting point for most of the business

critical analysis. An investment that

looks like risk management, P&L

accounting, regulatory compliance,

all these functions that are critical

for asset managers.

So, say two different sources of data

disagree about particular values.

Ideally,

that conflict doesn't get flagged before

it reaches the sec master.

You can go back to the sources and

pinpoint either the divergence in the

particular value, or sometimes it's a

logic problem and you can examine how

each one maps to that particular

security. So, when done correctly,

upstream problems are fixed before they

contaminate all the business critical

analysis we just talked about.

So, I like to think about this as an

organizational primitive for how you

handle data to enable all the consumers

of data at your company.

This layer separates the data producers

from the data consumers. So, whether

you're working on a complex medallion

data lake house that has many different

tables, or it's just a single

denormalized source of truth,

this is the bottleneck where you can

enforce the standards and the visibility

and the quality checks.

So, depending on where you invest,

you need to take this simple concept and

match it up with how everyone else in

the world who invests in this particular

asset class,

potentially speaking different languages

languages, settling in different

currencies, and operating in different

regulatory regimes.

So, for public assets, you benefit from

a couple different points of

centralization.

For the needs of exchange and

transactions, you have data vendors who

will

provide different identifiers. So, these

might be like Bloomberg figgies or LSE

RICS.

Then there's also regulatory needs. And

though that point of centralization

causes numbering agencies to offer a

different set of identifiers, like ISINs

or CUSIPs.

So, you're able to use this information

to map anyone's view of a particular

asset into your own view. And that's the

only way you can understand your

positions, like modeling risk or

reporting holdings, joining alternative

data, creating financial models.

So, let's take a very simple example.

You hold some mega-cap publicly traded

stock like Google.

So, already if you know the tickers,

is this GOOG or is this GOOGL? Because

there are two different share classes

traded on the same exchange.

Let's say you need to join in some data

that exists only at the level of the

legal entity. Well, if you're indexing

based off of ISIN, now you can't join

that anymore.

Or maybe you only trade one share class

and you only hold one, but you need to

trade it across multiple different

exchanges because you have different

funds for the needs of multiple

multiple funds or multiple investors.

So, already this is getting pretty

complex.

I like to think about this kind of like

a daytime library as a comparison for

the engineers.

It seems very simple when someone solved

the problem well.

But the moment you're either, you know,

working with a new language that hasn't

implemented good daytime yet, or you

just need to make some modifications and

peel back how it works inside, it's all

edge cases and complex ontologies. So,

this is what that Google example might

look like in practice. Here's a

denormalized table with many rows for

that one equity we want to uh able to

now analyze.

So, if some data comes in, even if it

only has a subset of identifiers or

exists at a different granularity than

your Sec Master, the code can still map

it.

So, here's where it gets interesting.

If the code if the data coming in

doesn't have regular identifiers,

how do you map it?

It's actually pretty clear how AI helps

in the first case, right? It's very easy

to reason about this data with

structure.

The coding agents are increasingly good

at writing code and if you have the

source of kind of gold standard ontology

about the business critical data for

your company,

But with unstructured, potentially not

identified data sources, you have a huge

burden of manual verification and manual

mapping.

So, this is where the happy path breaks

down when private assets come into the

Sec Master.

So, when you're buying the Google stock,

you know what you're paying,

you know what you're getting,

and going into the transaction, everyone

has a shared language of different

identifiers that they can speak.

Let's imagine you're going to lend some

money to a company building a power

plant near some data center developments

or you're investing in land near the

power plant

for potential future

uh development itself.

There's no identifiers everyone shares

going into that deal.

There are no one that regulates the entire

structure of information you might get

out the other end. And there's no one

data vendor that has a single API where

they've thought through the ontology of

these entities in particular.

Everything from the repayment schedule

to the collateralization, all of this

lives in one-off agreements or

amendments. It's not fungible.

The asset is captured and defined

entirely by the documentation.

And this is interesting because now the

data scales almost one-to-one with the

assets

and the burden to scale the the Sec

Master itself is constantly increasing.

Now, Cliff makes a really good point.

The private assets are an absolute pain

to manage. They just don't fit into the

Sec Master all that well. But all that

information still needs to actually be

collated in some way. It's not like your

audit requirements and your cleaning

requirements and your standardization

requirements disappear. If anything,

it's actually a lot worse now because

it's just so much less standardized. You

can't rely on the people who are doing

your risk modeling to know whether or

not that data is ground truth. You

certainly don't want them to be the ones

going through and munging through all

your documents. So, somehow the data

that lives in that PDF somewhere, that

information needs to make its way back

into your SecMaster.

And right now, that is just an extremely

high labor task. I mean, generally it

just takes a lot of people hours and a

lot of domain expertise. I'm also going

to really quickly move this mouse out of

the way. It's been bothering me.

All right.

So, I want to ground this in a specific

example. We work closely with a Fortune

200 asset manager here in New York, one

of the benefits of being New York local.

They recently started owning a bunch of

private assets, who hasn't, and it was

causing a lot of problems for their data

engineering teams, the people who were

maintaining their SecMaster. Now, when

any assets in their SecMaster changed,

they had to make sure that change was

correct. So, they had a system. They did

a day-over-day change analysis of their

table.

If you have a table with 50,000 assets

and each one of those assets has

something like 200 columns, even

infrequent changes are going to happen

on some daily cadence.

And every single one of those changed

cells was then sent to a team of people

to triage because, again, all of this

data is super unstructured. It just

lives in documents somewhere.

So, that team was then responsible for

going through docs and going through

various data sources to determine if any

given change was good or bad because

upstream data providers may have

fat-fingered something or may have

gotten something incorrect or they may

have just been conflict.

And I want to highlight that this is not

just every row, not every column,

literally every single cell. So, if an

asset changed price or if an asset

changed its name or if a company went

bankrupt or if it changed ownership or

you renegotiated a contract or whatever,

every single one of those changes in

that investment universe would have, on

average, an hour of work behind it. An

hour of somebody somebody's time,

somebody that you're paying to go and

just lunge through data. That is

hundreds of thousands of hours every

single month. Hundreds or thousands,

sorry.

So, we're at AIE, how would an AI

engineer solve this problem?

Two words.

Cloud agents.

What are cloud agents? This is more for

the finance folks in the room. In

simplest terms, a cloud agent is a

coding agent like Claude Code or

ChatGPT, but instead of running on your

local machine, it lives and runs in a

remote environment instead of on your

computer.

Because it lives on the cloud, we can do

a lot of really interesting things. We

can uh assert a bunch of audit

requirements, we can get auditability

and trans um transparency, we can get

observability, and more importantly, we

can have it spin up and do work on a

schedule without a person being

involved.

For example, when new data hits the SEC

master.

So, whenever there is a change in the

investment universe for this particular

asset manager, a Nori cloud agent will

spin up, in this case running a locally

deployed open source model under the

hood, so all of the data stays on prem.

There is no concerns about information

getting out of the underlying

environment. The agent here has explicit

instructions to figure out how the

source uh figure out the source of this

change. And it also has access to a few

useful tools, Box for PDFs, public APIs

like Bloomberg, and even a small segment

of email.

The agent then assembles an explanation

of the change, gets citations for why

that change happened, and then provides

a recommendation for whether to keep or

discard it. And finally, it pings the

owner of whichever cell changed in Slack

for review.

So, you have this agent that is

operating basically entirely

autonomously, providing tasks for a

human that the human just has to say yes

or no to. And of course, if necessary,

the human can go and do further research

to make sure that the information

provided was correct.

Now, you still need a human to review

those changes. Of course, this is

necessary just for accountability among

other things. But, this kind of work

dramatically cuts down the response time

because most of the previous slowness

was just people having to manually

search through a bunch of documents.

Agents are really, really, really good

at that, and humans are pretty bad at

that. So, if most of the time is just

assembling a case, well, you can take

something that used to take an hour and

make it just 5 minutes of human work.

ask, how does the agent actually get

domain expertise? How does it know what

a good change looks like? I'm concerned

that some of the folks in the room might

think, "Oh man, I have to go and build

this like custom agent infrastructure

that going to do this really, really

specific one-off thing."

Well, I don't think that's actually how

these things should work.

Agents get information the same way a

new analyst does, from written

instructions about where documents live,

which sources to trust, and how to judge

a change, all in English. Agents are

pretty good at self-modification these

days. So, you can change how an agent

behaves by just editing natural language

English markdown files. You use a

generic agent like Claude Code or Open

Code or anything that's open source like

Pi, and then you skin those agents with

configs like skills or agent MD files.

And most of the customization actually

comes from the environment in which the

agent is running in, which of course is

just about what kind of configs and what

kind of credentials you're dropping on

the machine.

So, I want to take a step back and zoom

out a little bit.

Everything that we've talked about so

far, this agentic SecMaster concept,

this is essentially a database with a

bunch of cleaner fish automatons that

are dynamically making sure that

everything is up to date.

They can spot problems quickly and

proactively surface them and even solve

them in some cases, all autonomously.

And one of the things I want to

highlight is that this technology is not

limited to SecMasters or even data

cleaning in general. It can be useful

across a firm because it is a generic

primitive in which we are having agents

do work that was previously loaded onto

humans.

In my mind, the incredible potential of

AI tools in finance is that they can

make a huge range of tasks proactive

instead of reactive. Right now, every

time anything needs to happen, and a

human has to spend time and energy

evaluating whether or not that task is

worthwhile and then sending that work to

an agent. If you ask me, the future of

enterprise AI is not use a robot on your

laptop to solve a problem. It's having

the robots come to you with tasks,

advice, analysis, and recommendations.

I think that in order to make that

future a reality, you need to use

flexible infrastructure that can be used

for any task and make it really, really

easy to modify what kind of tasks it's

being used for. Your SecOps master agent

shouldn't be a one-off unique agent. It

should actually be running on the same

cloud agent infrastructure as your audit

agent or your code review agent or any

of the agents that your engineers are

using for their day-to-day job.

Each of the Each of these agents will

have different instructions and tools

and triggers, different context. That,

of course, is owned by you, by the

company.

But the orchestration, the security, the

integrations, all of that should

actually just be the same across these

different tasks. And really, in my mind,

should just be owned by a vendor because

everybody is inventing these problems or

solving these problems over and over

again in the same organizations.

So, what were the things that we learned

by building AI for finance? I want to

leave with three lessons that we that we

had that I want to impart on everybody

here.

First, if you ask me, AI adoption is

primarily a collaboration problem.

People want to buy solutions, engineers

want to sell building blocks. We have to

find a way to meet in the middle. We

found the most success when we work with

brilliant folks who are experts in their

domain, who are able to make the leap,

that intuitive leap from cloud agents to

wait, this actually fits into a problem

that I have right now today.

Second, I think it's really important to

aim for 95% automation and it's okay to

keep a human in the loop. People want to

use AI to do 100% of everything and this

doesn't work. It doesn't work in

software, we've seen that with software

factories over and over again, but it

really doesn't work in finance.

It's okay to have a human in the loop.

In fact, I think we should lean into it.

There are way more problems that you can

solve if you're okay with having one

human spend 5 minutes looking at

something than trying to have an agent

do something 100% end-to-end every

single time.

And finally, I want to point out that

the cost of accidental complexity has

dropped significantly.

Fred Brooks used the phrase accidental

complexity to describe the difficulty

that comes from how a system was built

as opposed to the problem it solves. And

I think in the back office, a lot of

work is actually shaped like this. Teams

record the same data in different ways,

and vendors use different formats,

mostly because that's just how things

evolved organically.

I think agents are really, really good

at handling this kind of work, this

low-complexity, high-effort work, which

actually then allows people to spend

more time on the problems that are

essentially complex, the problems that

are actually hard.

So, that's all I got, guys. Thank you so

much for coming. Uh before I go, I want

to just quickly highlight two things.

One is if you're interested in more

talks like this, we run a community

called Agentics NYC. It is New York's

largest agentic engineering community.

We run regular events on building with

agents for beginners through experts.

And second, if you are interested in

cloud agents, software factories,

agentic back office, SecMasters, all

these different things, uh you should

reach out. Cliff and I will be in the

hallway track immediately after this. Uh

and of course, you can check us out at

noriagentic.com. Thank you so much.