TEF Extensibility vs Legacy L3 Modifications

If you have been in T24 long enough, you have seen the pattern. A business requirement comes in. It needs a change to a standard T24 routine. The quickest way to make it work is to modify the core routine directly — change the jBC code, recompile, and move on. It works. The business is happy. The project is delivered on time. You feel good about yourself.

Then the next upgrade comes. The core routine that was modified has been updated by Temenos. The local modification conflicts. The upgrade fails. Someone spends three weeks analysing the conflict, rewriting the modification, and retesting everything that depends on it. The business asks why the upgrade is taking so long. The platform team says "legacy modifications." Everyone is frustrated. The person who made the original modification has left the bank, and their documentation is a comment that says "// fix for issue #12345" with no reference to what issue #12345 actually was.

This article is about the alternative — the Temenos Extensibility Framework (TEF) — and why it is the right way to handle local developments in a modern T24 environment. It is also about why you should probably stop letting developers modify core routines just because it is faster in the short term.

What is an L3 modification?

Temenos classifies customisations into three levels. Knowing these levels will not make you a better T24 professional, but it will help you sound like one in meetings:

• L1 — Configuration. Changes made through the T24 interface — setting up products, defining user roles, configuring OFS.SOURCE records. These are safe. They do not touch the code and survive upgrades with minimal effort. This is the kind of change that business analysts make, and they are the heroes of every upgrade project.
• L2 — Local development. New routines, new versions, new enquiries that extend T24 without modifying the core. These are also safe. They sit alongside the core code and are not affected by upgrades. This is the right way to add functionality to T24, and it is the approach that every T24 developer should default to.
• L3 — Core modification. Changes to Temenos-supplied routines, tables, or screens. These are dangerous. Every L3 modification creates a conflict point for the next upgrade. This is the approach that every T24 developer defaults to when the deadline is tomorrow and the business analyst is standing behind them.

L3 modifications are the problem. They are the reason upgrades take months instead of weeks. They are the reason banks stay on outdated releases. And they are almost always avoidable. The phrase "we had to modify the core" is usually followed by "because we did not have time to do it properly," which is the IT equivalent of "the cheque is in the post."

What is TEF?

The Temenos Extensibility Framework (TEF) is Temenos's answer to the L3 problem. It provides a set of extension points that allow you to add functionality to core T24 processes without modifying the core code. It is the difference between renovating a house by knocking down load-bearing walls and renovating it by adding new furniture. One of these is upgrade-safe. The other is how you end up on the news.

TEF works through a plugin architecture. Instead of modifying a core routine, you write a Java class that implements a specific interface and register it with the framework. When the core routine reaches the extension point, it calls your plugin. Your plugin runs. The core routine continues. No core code is modified. The upgrade applies cleanly. Your plugin continues to work. Everyone is happy.

The key extension points in TEF include:

• Before and after hooks. Run custom logic before or after a core operation — for example, validate a field before it is saved, or send a notification after a transaction is posted. This is the most commonly used extension point, and it covers about 80% of the use cases that would otherwise require an L3 modification.
• Override hooks. Replace a core operation entirely with custom logic — for example, implement a custom interest calculation method that the standard T24 does not support. Use this sparingly, because replacing core logic means you are responsible for maintaining that logic through future upgrades.
• Event listeners. Respond to business events published by the core — for example, update an external system whenever a customer record is created. This is the TEF equivalent of the event-driven architecture we discussed in the IRIS article, but at a lower level.
• Data enrichment. Add custom fields to core screens and enquiries without modifying the underlying table definitions. This is the extension point that makes business analysts happy, because they can add fields without waiting for a core change.

Why TEF wins over L3

The advantages of TEF over L3 modifications are not theoretical. They show up in every phase of the software lifecycle, and they show up in ways that directly affect your workload and your sleep schedule:

Upgrades.

When you upgrade T24, Temenos provides a new version of the core code. If you have L3 modifications, every modified routine needs to be analysed for conflicts. This analysis takes time. It requires someone who understands both the old modification and the new core code. That someone is usually you, and you usually have other things to do. If you have TEF plugins, the core code is untouched. The upgrade applies cleanly. The plugins continue to work because the extension points have not changed — and if they have, the change is documented and predictable. You can test the plugins in isolation and be confident that they will work in production.

Testing.

L3 modifications require regression testing of the entire modified area. If you modified the core payment routine, you need to test every payment scenario. This is why upgrade testing takes weeks. TEF plugins can be tested in isolation because they are self-contained. The core logic is unchanged, so the standard regression tests still pass. You only need to test the plugin behaviour. This is the difference between a two-week test cycle and a two-day test cycle.

Governance.

L3 modifications are hard to track. They are buried in the core code, often undocumented, and frequently forgotten. The developer who made the modification has moved on. The business requirement that drove the modification has been superseded. But the modification is still there, still causing conflicts, and nobody knows why. TEF plugins are registered in a central repository. You can see every plugin, who created it, what it does, and which extension point it uses. This makes audit and governance significantly easier. It also makes it easier to identify plugins that are no longer needed and can be retired.

Skills.

TEF plugins are written in Java, not jBC. This matters because Java developers are easier to find than experienced jBC developers. It also means that the plugin code can use standard Java tooling — IDEs, build tools, testing frameworks — that are familiar to a much larger pool of developers. Your jBC developers will need to learn Java, but that is a better investment than trying to find jBC developers in a market where they are increasingly rare.

When L3 is still the right answer

TEF is not a complete replacement for L3 modifications. There are cases where modifying the core is the only option. These cases are exceptions, not the rule, and they should be treated as such:

• Bug fixes. If a core routine has a bug that affects your business, you cannot wait for the next Temenos patch. You fix it in your environment and manage the upgrade conflict later. This is the most common legitimate reason for an L3 modification, and it is the one that causes the most upgrade pain. Document it carefully, because you will need to revisit it during the next upgrade.
• Performance optimisation. If a core routine is performing poorly and the performance issue is in the core logic itself, you may need to modify it. TEF hooks add overhead — they are not a solution for performance problems in the core. Before you modify the core, make sure the performance issue is actually in the core and not in your configuration. You would be surprised how often "the core is slow" turns out to be "the database index is missing."
• Features that do not have extension points. TEF covers the most common extension scenarios, but it does not cover everything. If you need to change something that TEF does not expose, you have no choice but to modify the core. When this happens, raise it with Temenos as a feature request. They may add the extension point in a future release, and your L3 modification can be replaced with a TEF plugin.

The key is to treat L3 modifications as exceptions, not as the default. Every L3 modification should be approved, documented, and reviewed regularly to see if it can be replaced with a TEF plugin. If you have more than a handful of L3 modifications, you have a governance problem, not a technical problem.

Governing local developments

Whether you use TEF or L3, local developments need governance. Without it, you end up with an unmanageable codebase that nobody understands and nobody wants to upgrade. The codebase becomes a museum of good intentions and abandoned projects.

A practical governance model for local developments includes:

• A central registry. Every local development — whether TEF plugin or L3 modification — is registered in a central system with the owner, the business requirement, the affected area, and the upgrade impact assessment. If it is not in the registry, it does not exist. If it does not exist, it will be overwritten by the next upgrade, and someone will have a bad day.
• A review process. Every new local development goes through a review that asks: can this be done with TEF? Can it be done with configuration? Is there a standard Temenos feature that already does this? The answer to at least one of these questions should be "yes." If the answer to all three is "no," you have a legitimate L3 modification, and you should proceed with caution.
• An upgrade impact assessment. Before every upgrade, every L3 modification is assessed for conflict risk. TEF plugins are assessed for API compatibility. The assessment drives the upgrade timeline and the testing scope. This is the step that separates banks that upgrade in weeks from banks that upgrade in months.
• A retirement process. Local developments that are no longer needed are removed. This sounds obvious, but every T24 shop has modifications that were added for a project that was cancelled five years ago and never cleaned up. These zombie modifications cause upgrade conflicts for no reason. If the business requirement no longer exists, the modification should not exist either.

The bottom line

L3 modifications are the single biggest source of upgrade pain in T24. They are also almost always avoidable. TEF provides a clean, upgrade-safe way to extend T24 functionality without touching the core code. The technology works. The patterns are well understood. The only thing standing between your bank and a manageable upgrade process is the discipline to use TEF instead of modifying the core.

The banks that have adopted TEF as their standard extension mechanism report faster upgrades, lower testing costs, and fewer production incidents. The banks that still default to L3 modifications report the opposite. The choice is not about technology — it is about governance. And governance is a decision that the platform owner makes. If you are the platform owner, make the decision now. If you are not the platform owner, send them this article. It might help.