First of three pieces examining the modern modelling stack.
On the shared drive of any sufficiently old finance team sits a file called Model_FINAL_v17_PostBoardComments_USE_THIS.xlsx. Next to it sits Model_FINAL_v17_PostBoardComments_USE_THIS_v2.xlsx, edited eight minutes later by a different analyst, and a folder marked "Old" that nobody is willing to delete. On a Teams chat, a colleague has asked which version went into the credit paper. Nobody is sure.
This is the symptom. The cause is that the team is treating a filename as a version control system, and a filename is not one. It is a record of belief about what changed, not a record of what changed. Version control is not a tooling decision; it is an audit-trail decision, and an Excel-only firm with a shared drive does not have one.
That sounds harsh. The regulators arrived at the position software engineers reached three decades ago, and most finance teams have not noticed. The rest is mechanics.
Model_FINAL_v17_PostBoardComments_USE_THIS.xlsx is not version control
The filename pattern is a recognisable industry tic. It survives because it is cheap, and because the consequences of a poor audit trail rarely show up in a single quarter. They show up when a regulator, an auditor, or an investment committee asks what the model said on a specific date, in a specific configuration, against a specific set of assumptions. The answer has to come back inside a working week.
A shared drive cannot answer that with any reliability. Filenames are mutable. Edit timestamps reflect when the file last opened, not when the analytical change happened. The model log maintained in a sheet inside the workbook is itself part of the artefact under review; it cannot vouch for itself.
A repository under git answers the question by construction. Every commit is a content-addressed snapshot. Every change has an author, a timestamp, and a message. Every release is a tag that cannot move without being seen to move. The mechanism remains the canonical pattern for tracking directory trees over time.[1]
What SR 11-7 and SS1/23 actually require
The United States Federal Reserve and OCC published SR 11-7 in 2011. The operative passage requires that model code "cannot be altered except by approved parties, and that all changes are logged and can be audited", with a comprehensive inventory of when each model was last updated.[2] The phrasing is procedural rather than prescriptive: the regulator does not name a tool. It names an outcome.
The UK equivalent is SS1/23, published by the Prudential Regulation Authority in May 2023 and effective from May 2024. Its five principles cover governance, identification, development and validation, lifecycle change management, and deficiency remediation. The lifecycle-change-management principle expects an auditable record of who changed what, when, against which authority, with sufficient documentation to allow an unfamiliar reviewer to reconstruct the model.[3]
Read those two documents back to back and the engineering implication is unambiguous. The supervisory floor is a logged, attributable change history that an outsider can reconstruct. A shared drive does not meet that floor. A repository under git does, almost as a side effect of how the tool works.
The ICAEW Financial Modelling Code points in the same direction for a broader UK audience. It synthesises seven organisations' standards and emphasises version awareness and change discipline as construction principles.[4] The Code does not prescribe git. The mechanism it describes is what git provides for free.
Where git is the right tool, and where it is not
The honest position is narrower than the evangelical one. For artefacts that are shaped like code, which includes Python, SQL, R, DAX, YAML, and CSV files, git is the obvious tool. Diff, blame, merge, history, tagged releases, and signed commits all work as intended. The cost of adoption is a week of habit change per analyst.
For the workbook itself, the picture is more honest. An .xlsx file is a ZIP archive of XML parts under the Office Open XML specification, which is a property of the file format and not a deficiency of git.[5] Git will store the binary, but a default git diff against two workbook commits returns "Binary files differ", which is true and useless.
Three patterns address this. The first is a textconv driver that unzips the xlsx and serialises the XML parts before diffing, giving a readable diff for formula and named-range changes. The second is Excel-aware diff tooling as a category. Tools exist that parse the xlsx structure and present a cell-level diff; a modelling team should evaluate the category on its merits rather than by brand. The third is a hash-snapshot: commit the SHA-256 digest of the workbook alongside or instead of the file, so that future re-runs can prove byte-identity to the model used at the board meeting. Where a large binary must live in the repository, Git Large File Storage stores the content on a remote and leaves a pointer in the tree. That is sound for storage, but it does not give a diff.
None is perfect. All three beat what most finance teams have today.
The assumption register is the unannounced win
The strongest argument for adopting git, in a firm that has no intention of leaving Excel, has almost nothing to do with the workbook. It has to do with a single file alongside it: assumptions.csv, one row per assumption, owned, dated, and source-cited.
A flat CSV register diffs cleanly under git. It blames cleanly: the discount-rate row that moved on 12 March from nine per cent to 9.5 per cent has a commit, an author, a message, and a link to whatever paper justified the move. The register is the part of the model that an auditor, an investment committee, and a regulator most want to see, and it is the part that Excel handles worst. Extracting it into a versioned text file is the highest-leverage move available to an Excel-first firm. This is the input-separation principle behind GIVE Analytics' layered scenario architecture carried one step further: separate the inputs, then version them.
The academic basis is older than git itself. Donoho and Stodden treat versioned code and versioned inputs as load-bearing pillars of reproducible computational work, not optional extras.[6] The finance application is the same argument with the names changed. The "we are not a Python shop" objection, an objection GIVE Analytics encounters often in financial services engagements, is unrelated to the case for the register.
Branching for a team of four analysts
Most analyst teams do not need gitflow. They need a single long-lived main branch, short-lived task branches measured in hours or days, and a tag for each release. This is the trunk-based pattern, and it is the right default for small modelling teams.[7]
A release-tag-only workflow is also defensible. No branching at all; every model release marked by an annotated tag (v2026.Q3-board, for example). For an FP&A team of three or four with a known release cadence, this is often appropriate.
Gitflow becomes justifiable when the firm has calendar-driven model releases with immovable freeze dates: a quarterly board pack, a regulatory submission, a re-rating exercise. The cost of gitflow is real (more branches to manage, more merge points to police), and it should be paid only where the calendar demands it. The canonical description of Driessen's original model is widely cited.[8]
Git hosts are not the interesting decision. GitHub, GitLab, Azure DevOps, and Bitbucket are all viable; the choice is usually dictated by what the rest of the firm already uses, and the differences matter less than the choice to host the repository at all.
Commits, tags, and the board-paper citation
The commit cadence rule is simple. Commit per analytical step, not per Excel save. One commit equals one defensible analytical change, with a message a future reader can act on. Conventional Commits gives a lightweight syntax (fix(discount-rate): correct quarterly compounding, for example) that maps cleanly to semantic versioning, and the Software Engineering Institute at Carnegie Mellon has documented the pattern for regulated audiences.[9]
Semantic versioning, applied to model releases, reads naturally. MAJOR for breaking changes to outputs (a methodology revision). MINOR for backward-compatible additions (a new sensitivity case). PATCH for fixes (a formula correction). Tag the release. Sign the tag where the governance policy demands it.
The board-paper citation is the payoff. The investment committee paper does not cite a filename. It cites a release tag, v2026.09.IC-pack, which is immutable, attributable, and reconstructible. That convention sits alongside the IRR conventions investment committees still rely on as one of the small disciplines that lifts the credibility of the underlying analytical work. Pre-commit hooks can enforce the parts of the standard that should not depend on analyst attention: format checks, lint, an openpyxl-based validator that the assumption register is sorted and contains a discount-rate row.[10]
The two-analysts-on-one-tab problem
Git will not solve this. If two analysts edit the same tab of the same workbook in parallel, the merge is not a software problem and git is not the right tool to ask. The answer is workflow: split the scenario, divide the model, agree the lock, or step out of the workbook into a structured format that does merge. The FAST Standard's emphasis on structural separation of model logic helps, and is widely adopted in UK infrastructure and project finance for related reasons.[11]
The honest version of the argument acknowledges this. Git is not a panacea. The workbook merge problem is real, the binary-diff problem is real, and the next piece in this series will discuss when the right answer is to leave Excel behind for the parts of the model that benefit from it. The case for putting the artefacts you already have under git, today, is not contingent on that decision.
What an Excel-first firm gains is narrower than the evangelical pitch and broader than the sceptical one. An auditable change history. An assumption register that diffs and blames cleanly. A release tag that the board paper can cite. A regulatory floor met by construction rather than by promise. The shared drive does not provide those. Git does. The rest is implementation. GIVE Analytics' data analytics practice treats this as table stakes for any modelling engagement.
Notes
1. Linus Torvalds, original announcement of git, Linux Kernel Mailing List, 7 April 2005. The framing as a content-addressable filesystem for tracking directory trees, rather than a conventional source control manager, is from this thread.
2. SR 11-7, Supervisory Guidance on Model Risk Management, Board of Governors of the Federal Reserve System and Office of the Comptroller of the Currency, 4 April 2011. The quoted passage is from the documentation and controls section.
3. SS1/23, Model risk management principles for banks, Bank of England (Prudential Regulation Authority), published 17 May 2023, effective 17 May 2024. Principle 4 (model lifecycle change management) is the operative reference.
4. ICAEW Financial Modelling Code, ICAEW Excel Community. A UK accountancy-profession synthesis of seven organisations' modelling standards.
5. ECMA-376 defines Office Open XML; the xlsx container is a ZIP of XML parts. Paul Hammant's note on storing unzipped office documents in git (2015) describes the textconv pattern.
6. David L. Donoho and Victoria Stodden, "Reproducible Research in the Mathematical Sciences" (2014); see also Donoho, "An invitation to reproducible computational research", Biostatistics (2010).
7. Trunk-Based Development, Paul Hammant (ongoing). The canonical reference for the pattern.
8. Atlassian Gitflow tutorial, based on Vincent Driessen, "A successful Git branching model" (2010).
9. Alex Vesey, "Versioning with Git tags and Conventional Commits", Software Engineering Institute, Carnegie Mellon University, 29 May 2024. See also Semantic Versioning 2.0.0 (semver.org) and Conventional Commits 1.0.0 (conventionalcommits.org).
10. pre-commit framework, pre-commit.com. Pro Git, Scott Chacon and Ben Straub, chapter 8, covers client-side and server-side hooks.
11. The FAST Standard, version 02c (FAST Standard Organisation, July 2019). The standard does not prescribe a version control system; it does emphasise structural separation, which is the precondition that makes versioning useful.