The pricing and billing layer for Temenos banks
Temenos runs your accounts, payments and ledger. itea P2B runs the revenue on top of them. Purpose-built for transactional banking, itea P2B prices every transaction event, manages negotiated corporate agreements and produces invoices your clients can reconcile, without waiting for a core release.
Keep the core you have invested in. Take control of the fee income it was never designed to manage.
Why Temenos banks add a dedicated pricing layer
Temenos is one of the most widely used core banking platforms in Europe, and for good reason. It is built to run accounts, balances, payments and postings at scale. Fee logic for transactional banking is a different problem. A corporate cash management client rarely pays a standard tariff. It pays a price negotiated at group level, with exceptions for specific entities, volume tiers on payments, a bundle for account services and a waiver that expires next quarter.
When that logic lives in core parameters, every commercial decision becomes a core change. Product managers wait for release windows. Relationship managers work around the system with manual adjustments. Billing teams reconcile spreadsheets at month end. The result is slower pricing, frustrated clients and revenue that quietly leaks between the agreement and the invoice.
The pressure is rising from two directions. Corporate clients expect fee statements they can reconcile line by line against their own treasury systems, and regulation is pushing in the same direction, with fee transparency requirements such as those in the EU Payment Services Regulation. A bank that cannot explain every fee it charges, quickly and consistently, carries both commercial and compliance risk.
A dedicated pricing and billing layer separates the commercial logic from the core. Temenos stays the system of record for accounts and postings. itea P2B owns tariffs, agreements, fee calculation and invoicing. It is the same model we describe in our overview of pricing and billing for banks, applied to a Temenos environment.
How itea P2B works alongside Temenos
itea P2B is fully API-enabled and built on a microservice architecture. It consumes transaction events from your Temenos environment through APIs, applies the right price for each client, account and service, and returns priced, billed and reported revenue for posting.
Because the pricing logic runs outside the core, it has no dependency on Temenos release cycles. A new tariff, a renegotiated agreement or a new bundle is configured in itea P2B and takes effect without a core change request. The platform is format-agnostic in how it communicates, so it can also take events from the payment engines, channels and in-house systems that sit beside Temenos.
The division of responsibility stays clean. Temenos keeps what it does best: accounts, balances, transactions and the ledger. itea P2B takes what a core was never designed to do well: commercial agreements, complex fee rules, invoices your corporate clients can read, and the controls that prove every charge is correct.
Take a single SEPA payment from one entity in a corporate group. The transaction event arrives from the Temenos environment. itea P2B identifies the group agreement that applies, places the payment in the right volume tier for the month, checks whether a waiver or bundle covers it, and prices it. The fee lands on the client's invoice with a clear line item and is returned for posting. The same logic applies to the next payment and the millionth one, with no manual step in between.
What itea P2B adds to a Temenos core
Event-based fee calculation
Every payment, collection, account service and liquidity transaction is priced as an event, from the data your Temenos environment already produces. No batch guesswork at month end.
Pricing at group, customer and account level
Set a price once for a corporate group and override it for a single entity or account. Fixed, tiered and volume-based pricing work together, configured by the business rather than coded by IT.
Negotiated agreements, bundles and waivers
Model what relationship managers actually agree with clients: bundles, rebates, temporary waivers and client-specific exceptions. Relationship pricing becomes a managed asset instead of a list of manual overrides.
Invoicing in the formats clients expect
Produce clear, itemised invoices as PDF, XML, e-invoice or ERP export, so corporate treasurers can reconcile bank fees against their own records without calling their relationship manager.
Revenue assurance
Match what was agreed with what was charged. Missed fees, waivers that outlived their end date and incorrect tiers surface before they turn into revenue leakage.
Audit and compliance
Every price, change and charge is traceable. When a client or an auditor asks why a fee was charged, you can show the agreement, the rule and the transaction behind it.
The fee types Temenos banks move first
Not every fee needs to move on day one. Most transaction banks start where commercial complexity and revenue at risk are highest. For corporate cash management that usually means payment fees: domestic, SEPA, instant and cross-border, each with its own tiers, urgency levels and client exceptions. These fees generate volume, they are negotiated hardest, and they are where manual adjustments pile up fastest.
Account services come next: maintenance fees, statement and reporting fees, and channel or connectivity charges. They look simple in isolation, but across a corporate group with dozens of entities and hundreds of accounts they become a large, recurring revenue line that is easy to under-bill.
Liquidity and cash concentration services often follow, because their pricing depends on how the client's structure is set up rather than on single transactions. Moving these fees into itea P2B one family at a time gives the bank a clear before and after on every step, and keeps each change small enough to govern.
The order is a business decision, not a technical one. Some banks start with the fee family that leaks most revenue today. Others start with the segment where client complaints about invoices are loudest, or with the entity whose legacy pricing system is closest to end of life. itea P2B supports any of these starting points, because each fee family is configured independently on the same platform.
Start with one product line, not a core project
The biggest risk in modernising pricing is scope. itea P2B is modular, so a Temenos bank can start with a single product line, client segment or entity. Payment fees for large corporates, for example, or one legal entity within a wider banking group.
The first scope goes live, proves the numbers and runs alongside the existing setup. Legacy pricing tables and side systems are then retired step-by-step as itea P2B takes over more products. There is no big-bang replacement, and because the platform has no dependency on core release cycles, the work does not have to wait for a slot in your Temenos roadmap.
That matters in a bank where the core roadmap is already full. Pricing modernisation becomes a business-owned initiative with a contained integration footprint, rather than one more item competing for core release capacity. The business sets the pace, IT keeps control of the integration, and procurement evaluates a scope it can actually assess.
What changes for the teams around Temenos
Product and pricing teams get control of their own tariffs. A new cash management package, a revised payment tier or a campaign price can be designed, approved and launched in itea P2B, instead of being written up as a requirement and queued behind other core work.
Relationship managers get agreements that behave the way they were negotiated. When a corporate client is promised a group price, a bundle or a temporary waiver, that promise is configured once and applied automatically to every transaction it covers. Fewer exceptions to chase, fewer awkward conversations about incorrect invoices.
Billing and operations teams stop rebuilding invoices by hand. Fees are calculated as transactions happen, invoices are produced in the format each client needs, and discrepancies surface as exceptions to review rather than as complaints weeks later.
Finance and control functions get a complete, traceable picture of fee income by client, product and entity. IT keeps a clean architecture: the Temenos core stays focused on accounts and postings, and pricing logic lives in one governed place instead of being spread across parameters, scripts and spreadsheets.
Built for European transaction banks
itea P2B is purpose-built for transactional banking and founded by people who have run it from the inside. That shows in the details: support for SEPA and instant payments, invoicing aligned with the EU direction on e-invoicing under ViDA, and pricing that follows how European corporate groups are actually structured, from group to entity to account.
Many European transaction banks run Temenos at the centre of a wider estate that includes payment hubs, channels and in-house systems. itea P2B works with the core you already run, whether that is Temenos, Finastra, Mambu or an in-house platform, so the same pricing logic can serve every part of the estate instead of being rebuilt in each one.
For the wider picture of what European transaction banks should look for, see our guide to pricing and billing for European transaction banks.
What Temenos banks ask before they start
Do we need to replace Temenos? No. itea P2B works alongside the core you already run. It reads transaction events through APIs and returns priced and billed revenue, so your Temenos platform stays exactly where it is.
Does every price change need a Temenos change request? Not for the commercial logic. Tariffs, agreements, bundles and waivers are configured in itea P2B, which has no dependency on core release cycles. Your Temenos team is involved in setting up the event integration, not in every price change that follows.
What does the integration involve? itea P2B needs the transaction events that drive fees, delivered through APIs, and it returns priced and billed revenue. Because it is format-agnostic in how it communicates, it adapts to the interfaces your Temenos environment and surrounding systems already use, rather than forcing a new standard on them.
Can one entity move while others stay on existing pricing? Yes. That is the intended way to start. One entity, segment or product line moves to itea P2B while the rest of the group continues as today, and the scope widens as each step proves itself.
Where does the charged fee end up? itea P2B calculates the fee, produces the invoice and returns the priced and billed revenue for posting, so your ledger stays complete and finance works from one set of numbers.
How soon do we see value? Because you start with one product line, segment or entity, the first scope is small by design. The early gains are practical: clearer invoices for clients, fewer manual adjustments for operations, and visibility into fees that were agreed but never charged.
Is itea P2B part of Temenos? No. itea P2B is an independent pricing and billing platform for transactional banking that works with Temenos and other cores. Temenos is a trademark of its respective owner.
Put a pricing layer on your Temenos core
Tell us which fees cause the most friction today. We will show you how itea P2B prices them, bills them and proves every charge, alongside the Temenos platform you already run.