[Expert Review] Legacy Banking: What did decades of financial systems teach us?

[willgittens]

Before microservices, cloud computing, REST APIs and AI, financial systems were already processing millions of transactions.

Many of those systems were written in COBOL, running on mainframes, processing massive batch jobs and maintaining financial records long before today's technologies existed.

And some are still running.

But here is something that interests us at FinKore:

What did those engineers learn that modern software development may have forgotten?

We would like to invite professionals who have spent years, or even decades, working with COBOL, mainframes, core banking platforms, financial batch processing and legacy financial systems to share their experiences.

This is not a discussion about whether COBOL is better or worse than modern languages. And it is certainly not about criticizing old systems.

It is about preserving knowledge.

FinKore is an open-source initiative working to make financial-system rules explicit, portable and verifiable across programming languages.

We believe some of the most valuable financial rules may already exist inside systems built decades ago, sometimes without ever being formally documented.

So, rather than asking you to review code or specifications, we would like to interview you.

No need to answer everything. Pick the questions that bring back memories, tell us what happened, and share what you learned.

---

Part 1 — Take us back to the beginning

1. How did your journey into financial software begin?

What was your first financial system? What language, platform and type of institution were you working with?

2. What was the first financial-system rule you learned that was very different from ordinary programming?

Something that made you realize financial software requires a different kind of thinking.

3. What was considered absolutely unacceptable in the systems you worked on?

Losing a transaction? Duplicating a payment? Incorrect balances? Missing audit information? Something else?

Part 2 — When things went wrong

4. Tell us about a production incident you still remember.

A batch failure, an incorrect balance, a duplicated transaction or a processing interruption. What happened, and what did the team do to recover?

5. How did your systems recover when processing stopped halfway through?

How did you know which transactions had already been processed and which ones were safe to execute again?

6. What happened when two operations attempted to change the same financial information?

How did the system prevent inconsistent balances or conflicting updates?

7. Did you ever encounter a financial discrepancy that the software could not explain?

How did you investigate it? What records or controls helped you identify the cause?

Part 3 — The rules hidden inside the code

8. Have you ever discovered a financial rule that nobody had documented?

Perhaps a strange condition in a COBOL program, an unexpected batch sequence or a calculation that nobody wanted to change.

What was the rule, and why did it exist?

9. Have you ever been told, "Don't touch that part of the system"?

Was there a real financial reason behind that warning, or had the original knowledge simply been lost?

10. What was the strangest financial requirement you implemented that eventually made perfect sense?

Sometimes the most unusual business rules exist because someone learned an expensive lesson years earlier.

11. Were there rules that existed in several different systems but were implemented differently?

For example, rounding, financial corrections, transaction identification or approval controls. How did those inconsistencies affect operations?

Part 4 — Modernization and lessons learned

12. Have you participated in migrating or replacing a legacy financial system?

What was the hardest part: translating the code, understanding the data, reconstructing the business rules or proving that the new system behaved correctly?

13. Did a modern replacement ever produce different financial results from the legacy system?

How did you determine which result was correct?

14. What important safeguards from older systems do you think modern developers tend to underestimate?

Consider transaction recovery, reconciliation, financial precision, auditability, end-of-day processing or any other area.

15. If you could give one piece of advice to a developer building financial software today, what would it be?

Something learned from experience rather than from a textbook.

Part 5 — Help us build something better

16. Which financial rules should behave consistently regardless of programming language or platform?

Imagine implementing the same financial operation in COBOL, Java, Go and TypeScript. Which outcomes should never differ?

17. If you could preserve three lessons from decades of financial software development for the next generation, which would you choose?

18. What question should we be asking experienced financial-system engineers that nobody seems to ask anymore?

---

Why are we asking these questions?

FinKore follows a simple process:

CoreDoc → Specifications → Conformance → Implementations

Before implementing a financial rule, we want to understand what that rule actually means, which conditions it must preserve, and which failures it must prevent.

Your experiences may help us discover missing requirements, challenge existing assumptions and create new conformance scenarios that future implementations can verify.

For example, a story about recovering an interrupted overnight batch might reveal a critical requirement for transaction identity or duplicate prevention.

A story about migrating a banking application might help us understand what financial equivalence between two implementations should actually mean.

And sometimes the most useful contribution is explaining why a supposedly universal rule only makes sense within a particular banking environment.

We are not looking for confidential code, customer information or proprietary business logic. Please anonymize institutions, incidents and sensitive details where necessary.

One last thing

Your experience matters more than the programming language you used.

Whether you worked with COBOL, PL/I, RPG, assembler, CICS, IMS, DB2, VSAM, AS/400, IBM i or other financial platforms, we would love to hear your stories.

You do not need to answer all 18 questions. Even a single detailed story can help us uncover something important.

If you spent part of your career keeping financial systems running, this is your invitation to help shape the foundations of the next generation.

What did decades of financial systems teach you that we should never forget?

---

Part of the FinKore Expert Review Program.

https://finkore.dev/

https://github.com/willgittens/FinKore