Financial Engineer

The term "financial engineer" is appearing more and more; used differently than the more common definition related to designing financial instruments. The term is being overloaded. It is my observation that most are getting this notion incorrect and are not really thinking very deeply about this notion.

Remember the "learn to code" movement? This article, To Code or Not to Code: should lawyers learn to code? The AICPA had a similar article asking if accountants should learn to code which they have subsequently removed from their web site. And then you have those believe that coding was going away, Soon We Won't Program Computers. We'll Train Them Like Dogs, Well, now it seems that anyone can code using an LLM.

But then you have Kurt Cagle saying, Data, Not Software, Will Determine the Next Ten Years and The Application is Scaffolding.

So, let me dig into the notion of the "financial engineer" as I see it.  But first, let me summarize how others see it.

Numeric explains their notion of the financial engineer in their article, Here Comes the Financial Engineer.  In that article, Numeric says:

“The old accountant is dead. There is no place for them in the world going forward. The modern accountant is almost like a data engineer — you need to figure out how to take business transactions and work with data in order to translate things into accounting.”

In that article, Numeric defines a finance engineer thus:

"Finance engineers own data pipelines, ship automations, and treat the general ledger as a system to architect rather than a process to execute."

In another article, The Finance Engineer Cup, they provide a slightly different definition:

"Finance engineers treat their own operations as a codebase and every pain point as a potential solution to build."

As I pointed out in another blog post, Spreadsheet Monkey, one audit firm is hiring what they refer to as "accounting engineers".  See the article, Former Audit Regulator Helps Set Up Accounting Firm Targeting 80% Automation. Paraphrasing, they describe

The role of an “accounting engineers” as someone that blends traditional accounting knowledge with computer science and system engineering skills.

In another blog post of mine, Accounting Informatics Professionals; inspired by the book, Legal Informatics, and further inspired from a discussion about nursing informatics in the paper, Informatics: Evolution of the Nelson Data, Information, Knowledge and Wisdom Model: Part 2; the term "accounting informatics professional" seems appropriate. Here in this article I describe informatics as follows:

Informatics is the discipline that sits at the intersection of information, people, and technology. Informatics is concerned with the practical application of computational systems to help people create, manage, communicate, and use information effectively.

And so, how do I see the notion of "financial engineer" or "accounting engineer" or "accounting informatics professional" and why do I see it that way.

First, there is a difference between an engineer and an architect.  In short: Architects decide what should exist. Engineers figure out how to make it exist.

Software engineers, information technology people, and knowledge engineers seemed to be charged with making things exist.

Second, accountants are going to be doing more "configuring" of systems and metadata rather than engineering systems.  Accountants are going to be creating and organizing declarative business related metadata and rules; not engineering systems.

Third, yes there will be some accountants involved as part of a team of specialists to engineer frameworks for accounting information systems; but that will be about .001% of accountants.  For example, it is not the case that every accountant being involved in creating something like Accounting & Audit by Design (A&AD) Framework or the Seattle Method or a pragmatic knowledge management system.

Fourth, what I see happening is software changing.  What has happened in the past is that business rules and business logic was intermingled within software code which was then maintained by software developers within applications.  Going forward, the business rules and business logic will be separated from software applications and maintained in declarative form and in a manner that is approachable by business professionals.

Fifth, considering number four above; software "engines" will be used more and more.  For example the notion of an "intelligence engine" as I mentioned in the blog post, AI-First, Digital-First, Graph-First.  What I have called a knowledge based system. These "intelligent engines" will do much of the heavy processing using the declarative business rules and business logic.  These "intelligent engines" will be used by both humans and human agents (e.g. neuro-semantic artificial intelligence) working as teams within the same work system.

Sixth, it will not be the case that every individual enterprise is going to "roll their own" platform or ecosystem. This is where global open industry standards come in. I mean, think about it.  How would it work out if every different retailer created their own universal product code scheme? Or, what if every different organization created their own proprietary intermodal shipping container as contrast to creating intermodal shipping container standards.

Seventh, most people talking about the financial engineer as working with data.  For example, Numeric does that in their article.  That is incorrect in my view and, besides, it cannot work.  Accountants, auditors, and analysts need to work at the "molecular" level, "organism" level, and "species" level of Atomic Design Methodology.  Those layers relate to information, not data; and accountants, auditors, and analysts understand this level. Data, the "atomic" level, should be the responsibility of  the IT department.

Eighth, and building on the seventh; the higher level artifacts, the "organisms" and "species" are effectively digital information Legos. Pre-verified best practices based templates, pre-verified canonical best practice based prototypes and exemplars, and other such pre-constructed structures what are proven to be correct which are then reconfigured and edited which is easier than creating such structures from scratch will be heavily leveraged. This reduces the need to master the nuances and subtleties of knowledge engineering.

Ninth, and building on the eight; very likely 80% to 98% will be "off the rack" or "made to measure" accounting artifacts that need a few minor adjustments here and there. These are easily handled by your average accountant, auditor, or analyst or perhaps with the assistance of someone with a little special training.  But "made to measure" and even "bespoke" digital information organisms are still possible. It will be that 20% to perhaps only 2% of "good practices" and "emergent practices" and "novel practices" that skilled "financial engineers" or specialized knowledge engineers or other heavy hitters will be called in for.

BOTTOM LINE: And so, the bottom line from my perspective is that there will absolutely be a demand for so called "financial engineers" or "accounting engineers" or "accounting informatics professions"; but these folks will be doing things like configuring systems, creating declarative business rules, curating metadata.  In this new role accountants, auditors, and analysts will add more value as: orchestrator of intent, curator of knowledge, maintainer of truth, creator of insight, builder of mission critical systems, and developer of knowledge products. Key to making all this possible is a proper foundation. Trying to retrofit legacy tools like electronic spreadsheets simply will not work.

In my view, accountants, auditors, and analysts own information pipelines.  Those pipelines historically have been documents; going forward they will be models. That information was historically consumed by humans.  Going forward the information will be consumed by both humans and machines many times humans and machines working together. That information has zero tolerance for error and historically the quality was pretty good, but it cost a great deal to achieve that level of quality.  Going forward there will still be zero tolerance for error, the information will be an order of magnitude higher in quality; and the cost of achieving that quality will lower. Productivity increases will be achieved by leveraging structured information and artificial intelligence.


Additional Information:

Comments

Post a Comment

Popular posts from this blog

Internationalized Resource Identifier (IRI)

Image
An Internationalized Resource Identifier (IRI) is a standard proposed by the IETF ( RFC 3987 ).  An IRI is a unique sequence of characters that identifies a resource.   IRIs are a generalization of URIs ( RFC3986 ) that permits a wider range of Unicode characters. A  Uniform Resource Identifier (URI) is a unique sequence of characters that identifies an abstract or physical resource.  The difference between an IRI and a URI is that IRIs use the more modern  Universal Character Set (a.k.a. UNICODE)  and URIs use the older ASCII character set. The newer IRI format is compatible with the older URI format. The most  current version of RDF  uses IRIs to identify resources. Don't confuse IRIs with URLs and URNs.  A URL is a web address. A URN is a Uniform Resource Name. This Venn diagram shows the relationship between these different tools: Why are IRIs and URIs important?  If you are thinking in terms of a single database, a silo ...
Read more

Example Financial Statement Holon

Image
As I have mentioned in other posts on my blog, a financial statement is a formal semantic structure , in fact a financial statement is a special type of formal semantic structure referred to as a holon . As I mentioned in my blog posts, Kurt Cagle and Chloe Shannon are providing a lot of very good information about holons on their substack. ( Here is Kurt Cagle's and Chloe Shannon's answers to my questions. Here is an example Kurt Cagle created of a financial statement as a DataBook.) I have provided a bunch of good examples of financial reporting frameworks and reports   In this blog post I want to focus on one specific financial statement and see if I can explain that a financial statement is a "container" of  blocks of information and the "information blocks" that the financial statement contains. Cagle and Shannon point out that a holon is made up of four distinct knowledge graphs that maximize coherence and operationalize the holon which are: The Sc...
Read more

Inhabiting Babel, A Manifesto for Responsible Meaning Engineering

Image
Inhabiting Babel, A Manifesto for Responsible Meaning Engineering is a book written by Nicolas Figay . This book is very practical and easy for a motivated business professional to read. For me, this book has both tempered my expectations as to what is possible and also reassured me of the real possibilities that exist if you do the required work. Accountants and auditors tend to be on the conservative side of the spectrum.  Me included. I am  actually rather conservative in terms of what technology might bring to the table for accounting, reporting, audit, and analysis. I have learned how to "cut the cards" when dealing with sales people and software vendors. What this book does is bring the wisdom from the experiences of an expert in system interoperability, enterprise architectures, and complex systems to helps motivated business professionals and technical professionals that truly want to understand artificial intelligence, cutting through the rhetoric and hype. This boo...
Read more