Some people may be astonished to know that daily profit and loss (P&L) exists let alone the capability to delivery it across multiple separate organisations and entities in an enterprise in a 15 minute increment. Some might ask why would anyone do this, which is a fair question. There are a number of reason’s this would be desirable even critical for some types of organisations. But before describing those its probably best to describe what P&L is.

What is Profit and Loss (P&L) ?

The simplest way to describe P&L is;

P&L is the current financial position of an organisation and its entities

it is also and indicator;

P&L is an indication of financial health and effectiveness of the organisation since the last P&L report

A more commonly used way to describe it is;

P&L is a financial statement that provides a snapshot of how much your company is making (revenue) compared to how much is being spent (costs and expenses)

Every organisation needs to understand its current position, health, effectiveness and the balance between outcomes or revenues in commercial organisations and costs.

Why should P&L be a Daily Report ?

Daily reporting is a cadence associated for the most part with Risk Management in highly regulated environments, but may also relate to eCommerce, ERP (enterprise resource planning), HCM (human capital management), Investment Banking & Asset Management (asset transactions/management), Insurance/reinsurance (portfolio creation and management), Regulatory Compliance. There are more.

The clear features of P&L immediately lend itself to financial and asset transaction risk offsetting and management. Being able to view both leveraged assets and multi leg transactions in flight gives a clear view of risk in a way that was not available before the 2007-08 financial crises. Further it supports a clear understanding of of true profit values, where there is nothing subprime about the data gathered and the true position of assets and liquidity.

How do I know how this works?

In fairness to my past client I won’t name them, but I know this because I worked on both the architectural design and interaction features design of such a system. I will describe the problems and some of the solutions of this extremely complex bespoke software system that was still 20% of an off the shelf system before it would need to be integrated with data sources and conform to international data security.

Architecture of Daily P&L

I managed to make the clear pitch to the chief architect of this organisation that the future interactive capabilities of the new system would be defined by two factors the systems architecture and the data architecture. Thankfully they agreed and because of this foresighted approach I was able to help define the feature set before the work-stream kicked off.

I started with who or what are the consumers of the reports and who or what are the originators of the data. One clear issue in complex technical ecosystems is that many vendors have managed to get their systems into critical areas and have locked them so they don’t talk to other systems. The proposal was therefore to create a super data layer that would consume data from most of the systems and use a couple of systems as validation checks and balances. Its important to have checks and balances especially in new computer systems to ensure rigorous data standards and indicate error before it becomes endemic and critical.

Data of Daily P&L

One of the most common errors in new technology systems is to loose sight of why are they being created and to try and put too many requirements and data sources into them. P&L is supposed to advise, indicate and assure it does not do anything itself that requires human intervention. In investment banking that’s the Desk or the Business Unit Controller (a form of very smart accountant) who determines the offsetting for each transaction or group of transactions according to the type of transaction, client preference to risk (KYC), portfolio or even certian types of books (since they are highly volatile). Other uses of P&L in Banking are to assure effectiveness of strategies, change, BAU, customer lifecycle management, asset portfolio updates, KYC etc.

With this client there were a lot of issues around the golden source ledger data (the final version of truth) since data was being staged to enter and be adjusted during in flight transactions. Essentially we needed to created roll up and roll down reporting across thousands of transactions, indicate patterns and maintain traceability for charging clients, regulatory compliance and loss (risk and offsetting management) and ensure liquidity. I’m fortunate to have experience and MSc level knowledge of enterprise data systems so creating a multi staging environment was a lot less complex that might be imagined. So this is what we did we create a ledger that maintained a 15 minute truth with every transaction traceable.

The difficulty was following and unmasking patterns, for example in order to offset risk transaction over a certain value in portfolio of books with preset values where traders broke down larger trade to hide their true origination we used IBM Fuzzy Logic to recombine them. Why would a trader break them up, well offset funds don’t appear in traders income so their bonus goes down. Offsetting was a negotiation between the BUC, Desk and Trader however that was changed so that unagreed offsetting became agreed at the end of each day, if no other negotiation was agreed. All trades found through Fuzzy Logic were automatically offset to the highest level prescribed by the portfolio or book in response the the practice of trying to hide them. And all communication between BUC, Desk and Trader was moved from standard email into the software to be included in the trade reporting.

Daily P&L Reporting

The initial plan was to use Tableau as the main output tool for standard and custom reports since it provided a nice graphic interface for executives to see and present the current state of the organisation. Ultimately however an API was set up to allow other tool to consume the data layer. The user group by this point was quite large including day traders, desk managers, business unit controllers, executives, regulators, para planners, asset managers, business banking clients etc.

Unfortunately I cannot show the system but it is still in use today by the 60+ business entities in the client and all the users indicated above.