A bank, insurer or asset manager has relatively little operational emissions of its own. Offices, vehicle fleet, energy use: these are present, but in most cases they do not outweigh what comes in through the portfolio. The ratio here is almost the reverse of what a manufacturing company faces: the largest part of the relevant sustainability data does not originate within the organisation's own walls, but at the parties it invests in, lends to, or insures. This difference determines where you need to look, and it explains why an approach that works for a factory cannot simply be copied here without adjustment.
Data on the organisation's own footprint is usually the easiest to find. Facilities management has energy and water consumption for office buildings, HR has travel data and commuting data, procurement has contracts with suppliers of office supplies, catering and IT services. This part of the data point register is comparable to what any service organisation keeps track of. The challenge is not the complexity of this data, but the attention it receives: because it is relatively small compared to the portfolio impact, ownership here is often defined more loosely than it should be.
The largest part of the relevant sustainability data sits in the financial products themselves: loans, investments, insured risks, assets under management. For every counterparty, it must be mapped out which emissions, which climate risk or which other sustainability indicator is attached to it. This data comes from various directions: reports from the counterparty itself, data from external providers that supply estimates where direct data is lacking, and internal models that combine these sources into a figure per position or per loan.
The sources are therefore rarely the organisation's own systems. A credit system keeps track of who has borrowed money and under what conditions, not what emissions that client causes. A portfolio management system keeps track of positions and valuations, not the climate risks attached to those positions. The sustainability figures are often calculated in a separate track and later linked to the financial data, which means the link itself is a vulnerable point: if a counterparty changes name, structure or reporting year, the link can break without this being immediately noticed.
Because not every counterparty publishes good sustainability figures itself, external data providers offering estimates, scores or ratings are used on a large scale. That is a practical solution, but it does not remove the problem, it adds a link. For every data point that comes from an external provider, it must still be recorded: which method was used, which assumptions were made, how old is the figure, and what happens if two providers give a different estimate for the same counterparty. Without that record, a report emerges that looks convincing but in the background runs on figures whose origin no one can trace anymore.
Within a financial institution, there are often multiple business units that partly use the same counterparty or the same underlying data point: a bank that does both lending and asset management may request or calculate an emissions figure for the same client twice, through different departments and different providers. Anyone who maps out where a data point already exists across multiple business units prevents the same question from being answered twice separately, with two potentially different outcomes. This is not only a matter of efficiency, it is also a matter of consistency: a counterparty cannot have a different climate risk in one report than in another without an explanation for that.
The method for building a data point register, tracing sources and assigning ownership does not differ fundamentally from what is needed in the energy sector, the real estate sector or construction. What does differ is where the centre of gravity lies: in those sectors, the largest part of the data sits within the organisation's own operations or in the direct supply chain, while in financial services the largest part sits with third parties over which you have no direct operational control. That does not change the structure of the work, but it does change the question of who can be held responsible for what, and which data points are even within reach to manage. Before answering that question, it is worthwhile to first clarify which data points are actually needed when multiple business units are involved, so that the register does not grow with figures no one consults.
Once it is clear which data points exist, where they come from and who manages them, a next question arises: how much of the work to gather, check and update those data points still requires human effort, and which part is repetitive enough to leave to a system. FTE TO AI calculates per task which part of the work can be taken over by AI, based on the tasks that emerge from the data point register, not on a prior estimate.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.