24 Sep 2026 · 26m · Yolandi de Weerdt, Ciprian Porutiu · 24 quoted facts
Ciprian Porutiu of Marsh argues that finance teams cannot get reliable speed from automation or AI until their data foundations are in order. Fragmented systems, competing definitions and weak governance mean automation only spreads errors faster. The fix is a shared language, made up of a taxonomy, a data dictionary and federated data domains, rather than one giant database.
The central tension is between pressure to move fast and the need to slow down first. Porutiu compares it to slowing for a curve so you can speed up after it. He says the foundation work must be rolled out in phases, with users involved early, and tied to business outcomes that boards and executives care about, or it will be dismissed as internal cleanup.
Porutiu says automating over fragmented, ungoverned data produces 'garbage in, garbage out'. Errors compound rather than staying level, so the order should be source of truth, standardization, governance, then automation.
He describes reporting as the last step after subledger, transaction processing and reconciliation. If those steps are weak, reports will be unreliable, however good the reporting tools are.
Porutiu argues that in large organizations a single database becomes unmanageable. Domains such as claims, revenue and servicing should be owned close to the ground and connect through a shared taxonomy and data dictionary.
He recommends bringing cross-functional teams into testing and design during phased rollouts. People who helped build the system treat it as theirs, which reduces fallback to old habits.
If foundation work is presented as internal cleanup, he says it will not be funded. Linking each phase to outcomes such as consistent regional reporting makes the value visible to executives and shareholders.
Porutiu says automation only exposes what is already broken. If data is fragmented or defined inconsistently, automation spreads and compounds errors, so the data foundation should come first.
It means data is split into areas such as claims, revenue or servicing, each owned by the team closest to it, while still connecting to the others. Porutiu says that in large organizations one huge database becomes unmanageable.
A taxonomy is a shared classification of things like accounts, cost centers and products. A data dictionary spells out what each term means, for example whether revenue means gross written premium or net earned premium.
Porutiu disagrees. He says reporting is the visible outcome of everything beneath it, and investors and boards rely on it for trust, so unreliable reporting signals deeper problems.
Porutiu recommends a carrot and stick approach: decommission the old routes, but also show each role what it gains, such as less admin work. He also suggests phased rollouts and involving users in design and testing.
Stated by the speakers. Each quote matches the transcript, which shows what was said, not that it is true.
Ciprian Porutiu says his role at Marsh has covered finance transformation, CRM work and setting up new products.
“Fortunately, the the role has been very kind to me and allowed me to run in all corners of the organization, from finance transformation to CRMs”
Porutiu says his work includes deploying AI tools for both colleague productivity and client- and partner-facing products.
“deployment of A I tools, both for colleague productivity, but also for the product, so client-facing and partner-facing applications.”
Porutiu describes financial results such as earnings per share discussed in quarterly reviews and earnings calls as lagging indicators.
“it's basically the the lagging indicators, the ones that everyone discusses in the quarterly reviews, in the E P S and every earning earnings calls.”
Porutiu says leading indicators beneath the surface create the conditions for reliable lagging results.
“But what is underneath it's the leading indicators and what creates the per the the the context and creates the situation for the lagging indicators”
Porutiu says different teams pull finance data from different sources, including fiduciary systems, master data, invoicing, Excel and emails, even at large firms.
“Someone is taking the data from fiduciary, someone is taking the data from some master, someone is taking the data from, I don't know, invoicing or anything else, or or even Excel and emails”
Porutiu uses a traffic analogy to argue that governance slows you down briefly so you can accelerate afterwards.
“the laws of um, circulation of traffic, it tells you go down to twenty miles an hour on that curve because you're gonna go off the road.”
Porutiu says organizations should establish a source of truth and standardize systems before automating.
“So you have to have a proper sequencing in which you establish the source of truth. You standardize the the systems”
Porutiu argues the solution is aligning on language, taxonomy, dictionaries and federated data domains rather than building one database.
“It's not a question of one database, it's more around aligning on language, aligning on standardization of taxonomy, dictionaries, and even federated data domains, you know?”
Porutiu says that, like errors in large language models, errors between manually bridged systems compound, and proper governance prevents rework.
“the errors compound, they don't stay with the stay at the same level, and it it prevents, if done properly, a lot of rework.”
Porutiu recommends phased rollouts that start with low-hanging fruit and scale up, to build trust.
“So this is where you go phase rollout, you know, you, you apply all the principle, the known principle of laws hanging fruit and take small and and scale.”
Porutiu says involving users in design and testing creates a sense of ownership when a system goes live.
“No, you bring them in the testing, you bring them in the design, and then by the time goes live, they're gonna be, oh, but this is mine.”
Porutiu says organizations should decommission old systems as a guardrail, paired with showing users what is in it for them.
“you definitely need to have both the the guardrails, you know, which is the stick, which is a certain point you actually decommission and prevent people from going there”
Porutiu describes the finance value chain as subledger, transaction processing, reconciliation and then reporting.
“So when you go from sub ledger put in order, you go into the transactioning processing in order, and then you go to reconciliation, and then you go into reporting.”
Porutiu gives the example that revenue can mean gross written premium to one team and net earned premium to another, so teams speak different languages.
“if for one revenue means gross written premium, for another one is the the the the net earned premium, or for one is the financial definition, for the other one is the sales definition”
Porutiu notes that revenue can follow US GAAP in one team and international accounting standards in another.
“for one is the gap definition, the other one is for the is the international standards definition.”
Porutiu says presenting data foundation work as internal cleanup makes it a sunk cost that executives won't fund.
“If you put it only as an internal cleanup, well, this is why I'm, you're a sunk cost.”
Porutiu says technology does not fix finance operations but exposes what is already broken.
“Yeah, I think, again, the technology doesn't fix finance operations, it simply exposes what is broken.”
Porutiu argues that the larger the organization, the more counterproductive a single database becomes, and data should be organized in domains owned close to the ground.
“Actually, the bigger the organization, the single database is counterproductive because if we organize our data in data domains in which the ownership stays closer to the ground”
Porutiu gives claims, revenue and servicing data as examples of separate data domains.
“if it's like a claims data, or if it's like a revenue data, or if it's like servicing data, it's very important”
Porutiu says a shared taxonomy should define basic terms such as account, active account, cost center, products and transactions.
“What's an account? What's an active account? What is a a cost center?”
Porutiu says the ability of data domains to connect through APIs is almost more important than the data itself.
“it's almost more important, the A P I than the than the data itself.”
Porutiu says that with a shared language, data can flow between finance, claims and underwriting domains.
“Then finance can take claims data, the claims will take, uh, you know, underwriting data, and everything else will flow.”
The host stated that Ciprian Porutiu's views on the episode do not represent Marsh or its leadership.
“Just a quick note for our audience that the views expressed by Ciprian on today's program do not reflect that of Marsh or its leadership.”
The host summarizes that automating without sequencing and standardization accelerates compounding errors, making governance a prerequisite for AI deployment.
“First, automating finance processes without established sequencing and standardization only accelerates compounding errors, making governance a strict prerequisite for A I deployment.”
Porutiu frames financial results as the visible tip of an iceberg, with data and capacity below the waterline driving them. This sets up why foundations matter.
“everything you see, you know, financial results, revenue, top line or bottom line, efficiency, savings, everything else is the top part of the iceberg.”
He explains how multiple sources of truth and ERPs slow finance down, and why governance and order must come before automation.
“You can't automate something, otherwise you're just gonna have garbage in, garbage out.”
Error compounds with manual bridges between systems, so he recommends quick wins and involving users in design to build trust.
“you bring them in the testing, you bring them in the design, and then by the time goes live”
Guardrails such as decommissioning old systems must be paired with showing each role what it gains.
“you definitely need to have both the the guardrails, you know, which is the stick”
Porutiu answers a listener comment by explaining that reporting sits at the end of the value chain and depends on shared definitions.
“if for one revenue means gross written premium, for another one is the the the the net earned premium”
He says data dictionaries mean nothing to a board unless tied to outcomes, otherwise the work is treated as a sunk cost.
“If the output is the data dictionary, who cares at the board level?”
The practical playbook: domains owned near the ground, connected by a taxonomy, a data dictionary and APIs.
“the bigger the organization, the single database is counterproductive”
Welcome everyone to the Emerge AI in Business podcast. Today's guest is Ciprian Porutiu, SVP of Strategic Initiatives at Marsh. Ciprian joins us on this episode to examine how enterprise finance teams must structure underlying data systems before deploying automation and A I tools. He details why organizations should prioritize standardized taxonomies, common data dictionaries, and federated data domains over single, monolithic databases. Today's episode is sponsored by Fynapse. Just a quick note for our audience that the views expressed by Ciprian on today's program do not reflect that of Marsh or its leadership.
In this episode, we cover how finance teams should structure their underlying data systems. To go deeper on this topic and learn how financial institutions are digitizing paper-based records to unlock usable data for A I. And using alternative data like public web and social signals to enhance risk assessment, download our free PDF report, AI in Financial Services Executive Cheat Sheet at Emerge dot com slash FCS one. That's E M E R J dot com slash F C S one to download your copy.
Now the conversation with Ciprian Ciprian, welcome to the Emerge AI in Business podcast.
Nice meeting you, Yolandi.
I should actually say welcome back, but it's been a while so I'm really interested to hear what has changed in your mind since the last time you were on the show, but also what has stayed the same. And I think something that everyone talks about currently is about finance needing to move faster and everything has to move faster. But I don't feel that the part of the conversation that doesn't get enough highlight or attention is what is also quietly slowing it down, what is preventing us from moving faster.
And it's really not just one big thing that's broken, right? It's if we think about the day-to-day, if we're thinking about the numbers that don't quite agree between the different systems, or nobody being absolutely sure about what is the current version or the latest version that they should be working on. Or um, close week turns into a complete scramble because there are gaps that we cannot explain, things like that. So I wanna start quite broad with you on that.
What is creating the most pressure for finance teams right now when it comes to their data and the systems sitting underneath it?
Sounds good. So since last time we spoke, not much has changed, a lot has grown, but I'm still in the middle of change, transformation, engagement. Fortunately, the the role has been very kind to me and allowed me to run in all corners of the organization, from finance transformation to CRMs to hm, setting up new new products. Obviously, now everything is A I, so accompanying journeys in different capacities in terms of engagement and the deployment of A I tools, both for colleague productivity, but also for the product, so client-facing and partner-facing applications.
So I'm still very much focused and my light motif is also the the people engagement. So obviously companies made of people, processes, technology, a lot of times we focus on technology because it's something that grabs the headlines much more than uh, than anything else. The processes are probably much less, and the people's perspective is also kept in the background, and maybe it provides a headline when someone lays off a lot of people to replace them with A I, no, but not necessarily from the perspective of how do we use our best resources and best assets, if you want, without calling people assets, to actually make the company become something that it's a competitive advantage, rather, just like one item in
the assets balance sheet, no? So, I'm still coming from the same uh, uh, perspective, but definitely finance data and data in general is is more more forefront of attention of everyone today. When automation is no longer an automation, it's an automation potentiated by an A I and LLMs and SLMs and everything that wants to make the things, as you said, first, faster, everything has to go faster. And whether you wanna go faster or you have to go faster, because you have competition, because you have markets, because you cannot wait, definitely the speed is something that comes up to mind.
But I always try to take a step back and say, o, obviously, everything you see, you know, financial results, revenue, top line or bottom line, efficiency, savings, everything else is the top part of the iceberg. It's above the waterline, everything, and it's basically the the lagging indicators, the ones that everyone discusses in the quarterly reviews, in the E P S and every earning earnings calls. But what is underneath it's the leading indicators and what creates the per the the the context and creates the situation for the lagging indicators to actually provide not just good results, but also reliable res results that one quarter is not up and then the next quarter is down and you don't know why.
Well, the why it's below the waterline now, below the waterline when you see the capacity that you have and you create in order to deliver those products, lagging, um, uh, in the indicators. This is where the reach, no, in which your expansion geographically or product or line of business, or deepening and cross sell and everything else occurs. So all these elements are not necessarily coming and popping up on the earning calls and on the lagging indicators, but are the condition, the sine qua non condition for the lagging indicators to to happen.
So I'm almost seeing this kind of not dichotomy, but the ability to convey the importance or of those hm, uh, elements that are the leading indicators in order to produce and generate the lagging indicators. Stop for a moment to to get a little bit of feedback, or what do you think?
Yeah, it's interesting because a lot of what you're saying sounds that it's mostly people, and I think built in there is also gonna be a lot of trust. How are you seeing data fragmentation and, you know, different data living in different pieces of the organization, having to do the same thing and at some point be consolidated, giving us different results? How is that adding to the friction that we're seeing and slowing down everything in finance?
Not just people, definitely people is my angle, but definitely people is not the only aspect. It's definitely the way we organize ourselves in workflows and processes and data, for short, we're talking about data. So, da data fragmentation is obviously one aspect to it, a standardized source of truth, you know, so if every single line of business, every single region, every single point of view of the organization could come up with their own source of truth, you know?
Someone is taking the data from fiduciary, someone is taking the data from some master, someone is taking the data from, I don't know, invoicing or anything else, or or even Excel and emails, you know, it happens even to the to the bigger houses. It's definitely something that starts and has a a big impact there. The fragmentation, the standardized source of truth, the fragmentation instead, as you mentioned earlier, the different ERPs and different system in different aspects, again, from the perspective of the individual um, um, um, aspects of the of the company is very important.
And on top of that, the governance and control of data, you know, so you were talking about speed, you know, well, every everyone has to go much faster because but if you think about it, the laws of um, circulation of traffic, it tells you go down to twenty miles an hour on that curve because you're gonna go off the road. So it's not necessarily a limitation for the sake of the limitation, but it's a limitation for the sake of being able to reaccelerate after the curb in order to go faster.
But there you need to, uh, slow down in order to pass, and then you go ahead. So standard standardized source of truth, definitely fragmentation, governance, and then you come up with automation. If you do it in the end, so the sequencing is also very important. You can't automate something, otherwise you're just gonna have garbage in, garbage out. So you have to have a proper sequencing in which you establish the source of truth. You standardize the the systems, and we're gonna talk a little bit later about that.
It's not, we're not talking about the big database, you know, and you can call database or data, or or cloud or anything. It's not a question of one database, it's more around aligning on language, aligning on standardization of taxonomy, dictionaries, and even federated data domains, you know? But you have the standardized truth, this fragmentation, the governance, and then the sequencing. Having those in order, it allows you to get to the automation, it allows you to get the full extent, profit and benefit from all the A I and all the capabilities that the L L Ms can provide.
Yeah, and not having those things in order, obviously, that is what creates the friction and the constant problems and constant mistrust in in systems. And we've heard from many organizations trying to fix it. So challenge one is identifying that, okay, this is a problem, it's a bit going faster is slowing us down if we're not doing it in the right sequence or taking the right things into consideration. But it seems like the fixing is also a challenge.
We see that teams try to fix everything at once instead of focusing on where the payoff will be the biggest first. And that is where I think the next part of this conversation is also gonna go is. I wanna ask you, which parts of finance feel the biggest difference when the underlying data gets more structured and it's executed better?
Again, the fragmentation, for example, is not just that you you have to lose a lot of time to to capture the data, but the problems also compound because then you have not just um, a manual bridge between system, but it's introduction of error. It's the same now taking the parallel with the L L Ms, the more you introduce error, the errors compound, they don't stay with the stay at the same level, and it it prevents, if done properly, a lot of rework.
So audit, uh, controls, everything that comes will basically bring you back to the to the beginning. Instead, if you have the proper governance, if you have the proper standardization, you don't need to. So, in many cases, I've seen a couple of things. The finance teams need to see the connection between the standardization and those lagging indicators that we were talking at the beginning. Cause if they see the leading indicators, the standardization, the data domains, the data dictionary, and taxonomy, simply as a back office, put put your house in order, we're always gonna have a problem connecting the two, making sure that the leading will actually lead into the lagging indicator.
And the second one, you need to earn that respect, and you need to earn that trust. So this is where you go phase rollout, you know, you, you apply all the principle, the known principle of laws hanging fruit and take small and and scale. That way, you can not only allow them to see the value that goes from leading into lagging, but also increase the trust that you can actually deliver. Now there's always the gap between what's the strategy, okay, the strategy is to get the data foundation right in place, and then let's execute.
Well, there's that gap in between. We have very good plans, but then we're in incapable of executing. So that strategy gap, it's extremely important that can be filled with this kind of trust exercise, you know, in which you identify the problem, you roll out the pace in phased approach, and then you get everyone involved, everyone interested, you know, the this cross-departmental, cross-functional, cross-geographies, cross-segments, whatever cross is necessary, bring them in in the process of implementing rather than in the process of, hey, we launched a new system, uh, take a look at it and learn how to use it.
No, you bring them in the testing, you bring them in the design, and then by the time goes live, they're gonna be, oh, but this is mine. This is not someone else's that I have to learn. This is mine. I brought it to life.
I I can see how invaluable that is in in building trust, but also getting the system to do what you need it to do. Because no one knows better what needs to be done than the people actually using it and and needing it. And obviously, I'm sure that in in your career you've seen so many teams having to go through these transformations. How long do they typically live in that old system before they realize that something needs to change?
Before they realize, okay, we need to now look at transformation, look at structuring our data, look at getting our people involved in developing what needs to happen next.
The old method of carrot and stick, no? So obviously, there will always be someone that will fall back into old habits. So you definitely need to have both the the guardrails, you know, which is the stick, which is a certain point you actually decommission and prevent people from going there, but it's not sufficient because that is the governance without the meaning of the governance. You have to have the carrot in which you gather what's in it for me for each individual roles that are crucial to the particular transformation to understand what's in it for them.
So then you don't have to only prevent them to go back to the old ways, but you actually show them that that's something for them in this new way of doing it. I'm actually doing less work and actually doing more meaningful work instead of admin work or whatever else it is. I'm able to do what before it took me a a week of tedious work. I'm doing it in one hour and it's it's actually fun. Now, so both carrot and stick with what's in it for me, but obviously, you this is not like a totally anarchic society.
Usually, the business are not the bigger they are, the the more structure that you have to have also those hard rates.
Yeah, uh, that makes sense. I think anyone could convince me if it says less admin and more of the exciting stuff, I don't even need the carrot, that's that's enough. So, something that I'm also wondering about, and this is a comment that we recently got saying that in this age where and it takes us back to again speed and I think you mentioned in the beginning that everyone wants to to get on the bandwagon, but a comment that we got that said reporting AC accuracy is a nice to have and not urgent at this stage because we're still in developing status.
What is your opinion on that? Someone saying, uh, reporting accuracy is a nice to have
So, taking uh, some suggestion from your outline, it's actually a leading into a leading into a leading indicator. So the reporting is the last one if you want from the value chain. So when you go from sub ledger put in order, you go into the transactioning processing in order, and then you go to reconciliation, and then you go into reporting. The reporting is the lagging, you know? It's something that occurs if you have all the other elements in order.
So if you speak different languages, if for one revenue means gross written premium, for another one is the the net earned premium, or for one is the financial definition, for the other one is the sales definition, for one is the gap definition, the other one is for the is the international standards definition. Well, then you don't speak the same language. So going again back to that, one of the requirements is to go in the right sequence in order to get to automation on one hand, and on the other one, on the other hand, reporting it's simply an an outcome, an output of something that it's already working and it's not error sequencing and not error propagating.
Now, so the reporting, it's actually very important. I mean, even the earnings call. I need to gain the trust of my investors. I need to to gain the trust and retain the trust of the of the shareholders. Well, I have to report, I have to say what I'm doing and how I'm doing and what I plan to do. But if this reporting stands on its own, without the bases and the other leading indicators feeding into the reporting, then yes, the reporting is faulty and unreliable.
And how important is it that it is reliable? I mean, you just mentioned, you know, you've got the you've got the investors, you've got the stakeholders, you've got a board full of people that that want answers. Will they accept an answer like, oh, we're still in the developing stages, so it's not accurate? Reporting is not accurate at the moment, but just ignore that for the time being.
That's always the balance, meaning for people at the top or for the people at the end of the value chain, data standardization will always be a strange and theoretical concept. So you have to make sure that everything you do at the basis in which you, you know, you create the data domains, you create the data dictionary and taxonomies, means nothing to a board member if you want. But every time you do something, you link it directly to the outcomes.
You link it to something that connects to the language that the board member or the shareholders or the or the C-suite speaks and understand. Don't keep it under wrap until, oh, I'm not gonna reveal what I'm doing. First of all, maybe I'm not doing it fast enough, so I'm not gonna say I've done it before I've done it. But especially, I don't tie it to those outcomes. And it's extremely important to piece it out, and also that that phase rollout should be including always things that connect to the actual outcomes, not to the output.
If the output is the data dictionary, who cares at the board level? But if the data dictionary allows you to say now, across the whole region or across the whole segmentation of clients, I am able to report something that it's real and everyone speaks the same language, it's different.
Okay, that makes sense. And the picture that I'm seeing in my brain, as like you mentioned, the sub ledger handling transaction processing, reconciliation cycles, the way the we will only know if those things, even though they happen in sequence, we will only know if they are up to standard if we do get accurate reports. So it it's more than just keeping one person happy, it's and also determining whether your sequence is making sense and your your systems are making sense and the workflows are actually working.
yes. So there's more to think about than just plain simple reporting accuracy. Is that correct? Hm.
Absolutely. The reporting is not reporting in itself unless it ties to the actual strategic objectives or the specific objectives that the company has for the year or for the three years, you know, it always has to have that tied into the business outcomes. You can't do things just be, oh, this is internal cleanup. Well, then I don't care about it. I'm not gonna fund that. If you put it only as an internal cleanup, well, this is why I'm, you're a sunk cost.
You do cleanup in your room every day, so I I don't care what you're doing. But no, it's added value, it's not internal cleanup.
That makes complete sense. Super, I want to move into the practical part of this conversation. We're also reaching the the final part of the conversation. And this is where we get to give our audience members some very valuable information and leave them with something like a playbook or a strategy. And I know that our audience members in this line of business, they already know that the foundation matters, but they don't necessarily know exactly where to start.
They either try to fix everything all at once, like we mentioned earlier, or they'll try and do small little fixes here or there, but it never really comes to a point of conclusion. So, taking all of that into considerations, what are the first most effective steps that you've seen work in in a finance team where they're trying to move forward with something in real time and something that is technology supported?
Yeah, I think, again, the technology doesn't fix finance operations, it simply exposes what is broken. You know, so technology in itself doesn't do much in itself, really. What I wanted to uh, emphasize, and I think the next practical steps for any organization of any scale or anything, including mine, is common language, not necessarily a single database. What I said at the beginning, it's it's not a single database that it's important. Actually, the bigger the organization, the single database is counterproductive because if we organize our data in data domains in which the ownership stays closer to the ground, meaning if it's like a claims data, or if it's like a revenue data, or if it's like servicing data, it's very important
that the ownership stays close to the ground. But at the same time, they have to speak with the other domains because at the end of the day, they're reporting that famous reporting will pull data from each of them, and they will need data from the the the next door domain. So why is important to actually have a taxonomy that, you know, a common classification of accounts? What's an account? What's an active account? What is a a cost center?
What are the products? What are the transactions? This is extremely important in order to speak the same language and make those data domains speak to each other, rather than having everything in one unmanageable mammoth, uh, database, whether it's lake, cloud, whatever it is. But I mean, the conceptual data domains that are able to speak to each other because they have a taxonomy and they have a data dictionary, you know, or mentioning earlier the various point of view of the revenue.
What is this revenue from the sales perspective, or from accounting perspective, from U S perspective, or from international point of view? So having all these also very clear and these federated data domains with ownership very clear, but uh, the data domain more important is ability to connect to each other, you know, so ability to almost it's almost more important, the A P I than the than the data itself. If you're able to transfer and speak the same language and connect various data domains, then you have this triangulation of taxonomy, data dictionary, and data domains working together, and that is a data foundation that allows you to do anything else, automation, reporting, A I, anything you want.
I think the ultimate message just before we wrap up is just like with any organization, you have different departments that need to connect with each other, need to communicate with each other. That's the exact same thing that your data needs to do throughout the organization. Speak the same language, have those team check-ins, basically, sync with each other, and then we'll see flows starting to happen seamlessly. Is that the right picture to paint?
Yes, the foundation is we speak the same language, then the data will flow as needed. Then finance can take claims data, the claims will take, uh, you know, underwriting data, and everything else will flow. Important is that we speak the same language, so we trust what we query from the other neighbor data domain.
Yes, uh, valuable information and a very interesting way to think about it. Ciprian, it's been great having you back on the show. Thank you so much for sharing with us, and we hope to have you back soon.
Absolutely, it was a pleasure and always good to talk about those things.
Wrapping up today's episode, I think there are three key takeaways from our conversation with Ciprian. First, automating finance processes without established sequencing and standardization only accelerates compounding errors, making governance a strict prerequisite for A I deployment. Second, reliable finance reporting is a lagging outcome of stabilizing operational subledgers and transaction workflows beneath the surface, rather than an isolated back office task. And finally, establishing A P I connectivity across specialized data domains yields far greater agility and governance than attempting to consolidate all enterprise information into a single database.
In this episode, we covered how finance teams should structure their underlying data systems. To go deeper on this topic and learn how financial institutions are digitizing paper-based records to unlock usable data for A I. And using alternative data like public web and social signals to enhance risk assessment, download our free PDF report, AI in Financial Services Executive Cheat Sheet at emerge dot com slash F C S one. That's E M E R J dot com slash F C S one to download your copy.
On behalf of the team at Emerge, we'll see you on the next episode.