Let Digiqt design a funds transfer pricing engine whose every charge can be explained to the business head paying it.

Make Internal Funding Prices Defensible

# Pricing Internal Funding So Business Units See What They Actually Cost

Funds transfer pricing is where a bank's balance sheet economics meet its internal politics, and the engine usually loses. A methodology gets agreed, rates start flowing into unit profitability, and within two quarters the monthly performance meeting is spent arguing about the charge rather than about the business that incurred it.

That outcome is an architecture problem more than a methodology problem. A funds transfer pricing engine that cannot explain a rate, at deal level, in terms a business head recognises, will be treated as an accounting overhead and ignored. One that can explain it changes lending and deposit behaviour within a quarter, which is the entire point of building it.

## What is a funds transfer pricing engine actually for?

To charge users of funding and credit providers of funding, so unit profitability reflects real balance sheet economics.

Without it, a five-year fixed-rate loan and an overnight deposit appear to cost the same to fund, so business units are rewarded for taking term and liquidity risk the treasury absorbs invisibly. The engine moves that cost to the decision point. The Basel Committee's liquidity principles are explicit that liquidity costs, benefits and risks should be allocated to all significant business activities, which is precisely what internal pricing operationalises.

### What does an FTP rate have to charge for?

Term funding cost, liquidity premium, contingent liquidity, and the specific risks the business creates.

| Component | What it prices | Why it belongs |
|---|---|---|
| Base reference rate | The cost of money for the relevant tenor | Neutral starting point everyone recognises |
| Term liquidity premium | The cost of raising funding for that term | Makes long-dated lending carry its real cost |
| Contingent liquidity cost | Buffers held for undrawn commitments and outflow risk | Charges the business that creates the contingency |
| Basis cost | Mismatch between the reference rate a product pays and the funding basis | Prevents hidden basis risk sitting with treasury |
| Optionality cost | Prepayment rights, caps, floors, early withdrawal | Prices the option the customer holds |
| Regulatory cost, where genuinely attributable | Ratio impact driven by specific business | Only if attribution is defensible |

The last row is where methodologies overreach. If a regulatory cost cannot be attributed to a business decision in a way that business can influence, charging it produces resentment without changing behaviour, which is the worst of both outcomes.

### Why does a term liquidity premium matter more than the base rate?

Because it is the component that changes decisions, and the one most often flattened away.

A single pooled funding rate makes every tenor look identical, which is exactly the distortion that leaves a bank holding long-dated fixed-rate assets funded by overnight money. The term premium is what makes a five-year commitment feel different from a one-year commitment at the point somebody prices a deal. If your methodology has one number for funding cost, it is not really a transfer pricing system, it is an internal tax with a curve-shaped name.

> **Are your business units pricing long-dated deals against a single pooled funding rate?**
>
> [Talk to Digiqt about an FTP methodology and architecture review](https://digiqt.com/contact-us/)

## Why do FTP disputes happen so predictably?

Because charges arrive without explanation, and an unexplainable charge is always assumed to be wrong.

Three design flaws produce almost all of the arguing. Rates computed at portfolio level so no individual deal can be traced. Curves refreshed on an unclear schedule so a rate cannot be tied back to market conditions on the day the deal was struck. And allocations that cannot be decomposed into components, which turns every question into an escalation. The allocation-breakage pattern is familiar from any system that splits amounts across parties without traceability, exactly as described in this account of billing allocations that still break.

### Why does an unexplainable charge get ignored?

Because a price nobody understands cannot influence a decision.

If a relationship manager cannot see how pricing a deal differently would change the charge, the charge is noise in their world and they will price against the customer conversation instead. Explainability is therefore not a reporting nicety, it is the mechanism by which the whole system works. The test is whether a business head can be shown a single deal, see its components, and change the outcome by changing the deal.

### What must the engine store to answer a challenge?

The deal attributes used, the curve version, the component breakdown, and the methodology version, all as at origination.

Store the inputs and the decomposition alongside the result for every priced item. When somebody disputes a charge nine months later, you should be able to show which curve was in force, what tenor profile applied, and which components summed to the rate. That record ends most disputes immediately, and where it does not, it produces a specific methodology question instead of a general grievance.

## How should the engine be architected?

As a deal-level pricing service that locks a rate at origination and revalues only where methodology intends it.

Price at origination, at deal level, using the curve in force at that moment, then lock it for the term of the deal so subsequent curve movement affects treasury rather than the business that already made its decision. Where a product legitimately reprices, model that explicitly rather than by refreshing everything. Then keep the engine callable at pricing time, because the highest-value use of FTP is not the monthly report, it is a relationship manager seeing the funding cost before quoting. That means an API with latency low enough for a pricing screen, which makes it an operational service rather than a finance batch job.

### Deal level or portfolio level?

Deal level, always, with aggregation performed afterwards for reporting.

Deal-level attribution allows portfolio reporting, and portfolio-level attribution allows nothing else. It is also the only way to support pricing decisions, because a relationship manager needs a number for the deal in front of them. Volume is rarely the obstacle: pricing is a small calculation per deal, and the engineering work is in the data quality that makes each deal's attributes trustworthy, which is the same underlying constraint described in this guide to [improving data quality across legacy systems](https://digiqt.com/blog/legacy-skills-shortage-banking-technology/).

### How do you price products with no contractual maturity?

Through a behavioural tenor profile drawn from the same assumptions the ALM system uses.

A stable core deposit balance provides term liquidity even though it is contractually overnight, and pricing it at an overnight rate systematically under-rewards the business that gathered it. Split the balance into behavioural tranches with different tenors, apply the appropriate premium to each, and take the tranche profile from the same assumption store the ALM platform uses. Sharing that store is not optional. When [ALM and IRRBB assumptions](https://digiqt.com/blog/alm-irrbb-system/) diverge from FTP assumptions, the bank prices deposits against one view of behaviour and reports risk against another, and the reconciliation between them becomes a permanent unresolved argument.

## Which curves does the engine need, and who owns them?

A small set of authoritative curves with one named owner, one publication schedule, and versioned history.

Curve proliferation is the quiet failure mode: a treasury curve, a planning curve, an ALM curve, and a pricing curve that differ slightly and are each defended by a different team. Consolidate to one authoritative set, publish on a defined schedule with a version identifier, retain every historical version, and require every consumer to record which version it used. Where genuinely different curves are needed, for different currencies or funding programmes, make the difference explicit and documented rather than incidental. The intraday cash reality that validates those curves comes from the [real-time treasury platform](https://digiqt.com/blog/real-time-treasury-platform/), which is where actual funding behaviour becomes observable.

> **Running four slightly different funding curves owned by four different teams?**
>
> [Talk to Digiqt about curve governance and ownership](https://digiqt.com/contact-us/)

## How do you make results explainable to the business?

With a decomposition view per deal and per portfolio, plus a movement explanation between periods.

Give every user two things. First, a component breakdown for any deal or portfolio: base rate, term premium, contingent liquidity, basis, optionality, and any other charge, each with its value and the input that drove it. Second, an explanation of period-on-period movement attributed to volume, mix, curve movement, and methodology change. Those two views convert the monthly meeting from a dispute into a business conversation, because the debate moves from whether the number is right to what the business should do about it. Configuration matters here too: methodology should be versioned configuration rather than code, in the same way a well-built rating engine keeps pricing rules out of application logic so they can be changed and tested by the people accountable for them.

## How does FTP change behaviour, and how do you know it worked?

Through visible pricing at origination, and you measure it by watching what the business actually books.

The purpose is behavioural, so measure behaviour. After the engine is in place and explainable, look for shifts in the tenor mix of new lending, in the deposit gathering effort by product, and in how often relationship managers query a rate before pricing rather than after invoicing. If none of those change, the signal is not reaching the decision, and the cause is almost always that the rate arrives too late or cannot be explained. Adoption is the metric that matters, not calculation coverage.

## How do you change methodology without destroying comparability?

By versioning methodology, preserving locked historical rates, and publishing a bridge between old and new.

Methodology will change, because the balance sheet, the funding environment, and the regulatory framework all change. Handle it the same way you would a pricing model change: version the methodology, never retrospectively alter rates already locked to deals, restate a prior period under both versions for one reporting cycle, and publish the bridge so business units can see exactly what moved because of methodology rather than performance. Skipping the parallel period is what convinces business heads that FTP changes are a way of moving profit between units, and that impression takes years to undo.

## How should delivery be phased?

Curves and data first, then deal-level pricing for the largest products, then explainability, then pricing-time integration.

| Phase | Duration | Deliverable |
|---|---|---|
| Curve and data foundation | 2 to 4 months | Authoritative curves, versioning, deal attribute sourcing |
| Deal-level pricing for major products | 3 to 4 months | Origination pricing and rate locking for lending and deposits |
| Behavioural profiles | 2 to 3 months | Shared assumption integration for non-maturity products |
| Explainability and movement analysis | 2 to 3 months | Component decomposition, period-on-period attribution |
| Pricing-time integration | 2 to 3 months | Callable service in origination and relationship tooling |
| Methodology governance | Ongoing | Versioning, parallel restatement, committee process |

Note that explainability sits before pricing-time integration deliberately. Pushing an unexplainable rate into a relationship manager's screen accelerates rejection of the whole system rather than adoption of it.

## Which metrics prove the engine is working?

Coverage of balance sheet priced at deal level, dispute volume and resolution time, query-before-pricing rate, and behavioural shift in new business mix.

Track the share of assets and liabilities priced at deal level rather than allocated, which is the credibility base. Watch dispute volume and, more importantly, how long a dispute takes to resolve, since a good decomposition view should make most of them a five-minute conversation. Measure how often the engine is called at origination rather than in the monthly cycle, because that ratio tells you whether FTP is a pricing tool or a reporting artefact. And follow the tenor and mix of new business, since a working transfer pricing system should visibly change what the bank chooses to write.

Funds transfer pricing is one of the few internal systems whose success is measured entirely by whether people outside finance change their behaviour. That makes explainability the primary engineering requirement, and it is why the most sophisticated methodology in the bank is worth less than a rate a business head can see, question, and act on.

## Frequently Asked Questions

### What is a funds transfer pricing engine for?

It charges business units for the funding they use and credits them for the funding they raise, so unit profitability reflects the real economics of the balance sheet rather than a flat internal rate.

### Why do supervisors care about internal pricing?

Because allocating liquidity costs, benefits and risks to significant business activities is a supervisory expectation. Internal pricing is how a bank makes those costs visible where decisions are made.

### What causes most FTP disputes?

Unexplainable charges. When a business head cannot see which components produced a rate, the debate becomes political and the pricing signal stops influencing behaviour.

### Should attribution be at deal level or portfolio level?

Deal level, priced at origination and locked for the deal's term. Portfolio averages hide exactly the differences FTP exists to reveal.

### How do you price deposits with no contractual maturity?

Using the same behavioural assumptions the ALM system uses, applied through a tenor profile rather than an overnight rate, so stable balances receive credit for the term liquidity they genuinely provide.

### What components belong in an FTP rate?

A base reference rate, a term liquidity premium, contingent liquidity cost, basis and optionality costs where relevant, and any regulatory cost the business genuinely drives.

### How do you change methodology without breaking comparability?

Version the methodology, keep locked historical rates intact, restate prior periods under both versions for one reporting cycle, and publish the bridge between them.

### Why must FTP and ALM share assumptions?

Otherwise the bank prices business against one view of behaviour and reports risk against another, and no amount of reconciliation will make the two conversations agree.

## Sources

- [BCBS, Principles for Sound Liquidity Risk Management and Supervision](https://www.bis.org/publ/bcbs144.htm)
- [BCBS, Interest rate risk in the banking book](https://www.bis.org/bcbs/publ/d368.htm)
- [BCBS, Monitoring tools for intraday liquidity management](https://www.bis.org/publ/bcbs248.htm)

Funds Transfer Pricing Engine Design That Reflects Real Economics

Let Digiqt design intraday liquidity monitoring that satisfies your supervisor and gives treasury numbers it can act on.

One Intraday Liquidity View, Two Audiences

# Building One Intraday Liquidity View That Serves Treasury and the Supervisor

Most banks answer the intraday liquidity question twice. A reporting team assembles supervisory returns from month-old data, largely by hand, and a treasury team watches a handful of screens that show something different. Both outputs describe the same day, neither reconciles to the other, and the bank ends up defending two versions of its own liquidity usage.

That duplication is expensive and avoidable. Supervisory intraday measures and treasury's operational view need the same underlying data at the same granularity, and the only real difference is the cadence and presentation. Building intraday liquidity monitoring once, properly, removes a recurring manual burden and gives treasury something better than what it has now.

## What does intraday liquidity monitoring have to measure?

Liquidity used and available at every point in the day, including the peak, not a daily total.

The measurement problem is fundamentally about time. A bank can settle a large volume of payments and end the day flat while having been within a hair of running out at 11:40 a.m. A daily balance cannot show that. Intraday monitoring exists to make the shape of the day visible, and every design decision follows from needing timing rather than totals.

### Which indicators do supervisors expect?

A defined set of intraday tools with stress scenarios and a formal reporting regime.

The Basel Committee's framework for intraday liquidity management sets out seven quantitative monitoring tools together with stress scenarios, key application issues, and the reporting regime, with monthly reporting for internationally active banks having begun in January 2015. It is explicitly a monitoring framework rather than part of the liquidity coverage ratio calibration, and national supervisors decide how it applies to banks that are not internationally active.

| Measurement area | What it captures | Why treasury also wants it |
|---|---|---|
| Daily maximum liquidity usage | The peak intraday shortfall | Sizes the intraday buffer you genuinely need |
| Available intraday liquidity | Balances, credit lines, collateral, unencumbered assets | Tells you what you could draw on right now |
| Total payments made and received | Gross flows through the day | Shows dependency on inbound timing |
| Time-specific obligations | Payments with a hard deadline | The obligations that cause incidents when missed |
| Value of payments by counterparty | Concentration of inbound and outbound | Reveals who you are relying on |
| Intraday credit line usage | Draw against provided facilities | Cost control and dependency management |
| Throughput through the day | Share of value settled by each hour | Detects late-day clustering before it bites |

### Why is treasury's need different from the supervisor's?

Same data, different cadence: the supervisor wants a monthly record, treasury wants to act today.

Supervisory reporting is retrospective, standardised, and needs to be reproducible. Treasury needs a live view, thresholds, and an alert that reaches someone who can act within minutes. Those are presentation and pipeline-latency differences, not data differences, which is why one platform with two output paths beats two platforms. The failure of splitting them is the same one described in this account of why liquidity stress gets misdiagnosed, where the measurement chosen for reporting hides the behaviour that actually causes the problem.

> **Assembling supervisory intraday returns by hand from month-old data?**
>
> [Talk to Digiqt about an intraday liquidity monitoring assessment](https://digiqt.com/contact-us/)

## What data does the platform need, and where does it come from?

Timestamped payment and balance movements, credit line and collateral positions, and settlement account activity.

The analytics are arithmetic. The difficulty is that most of the required data lives in systems built to produce daily figures, so the fields you need either do not exist or are not preserved.

### Why are timestamps the critical field?

Because a peak cannot be computed from data that only records a date.

Every payment, receipt, credit draw, and collateral movement needs a reliable timestamp at the granularity of a minute or better, in a known time zone, recorded at the moment that matters rather than at the moment a batch process wrote the row. That last distinction catches many programmes: a settlement recorded with the timestamp of the nightly load is worse than useless, because it looks precise. Audit the provenance of every timestamp before trusting any computed peak, and record both the event time and the ingestion time so lag is measurable rather than assumed.

### Which sources are hardest to obtain?

Credit line usage, collateral availability, and correspondent account activity.

Balances in your own settlement accounts are usually accessible. Intraday credit line usage frequently sits with the provider and arrives late. Collateral availability spans a collateral system, a custody position, and a haircut policy that may live in a spreadsheet. Correspondent account activity depends on the correspondent's intraday reporting, which varies from rich to nonexistent. Model each source's reporting capability as data, show staleness explicitly in every view, and treat improving a weak feed as a relationship conversation with a technical specification attached rather than an internal engineering task.

## How do you compute peak usage and throughput correctly?

By replaying the ordered event stream and tracking the cumulative net position, not by aggregating daily figures.

Sort every liquidity-affecting event by timestamp, walk the day, and track the running net position along with the resources available at each moment. The largest shortfall is your peak usage, and the profile of settled value by hour is your throughput. Both fall out of the same replay, which is why an event-based data model is not an architectural preference here but a requirement. Recomputation from an immutable event log also means a late correction reprices the day without destroying the previous answer, and the ingestion patterns behind that are the ones described in this guide to [real-time analytics for operations](https://digiqt.com/blog/real-time-analytics-platforms/).

### How do you handle multiple currencies and time zones?

Compute per currency and per settlement location first, then present a consolidated view with the basis stated.

Liquidity is not fungible across currencies intraday, so a consolidated single number can hide a shortfall in one currency masked by a surplus in another. Compute and report per currency and per settlement account, then aggregate only for management summary with the conversion basis and timestamp shown. Time zones need the same discipline: store everything in a single canonical zone with the local settlement zone retained, because a peak at 16:00 in one market and 16:00 in another are different events and a naive aggregation will invent a peak that never happened.

### What about payments you have committed to but not yet made?

Include them as known future obligations, clearly separated from settled events.

The value of intraday monitoring at 11 a.m. depends on what is still to come, so the model needs queued and scheduled outbound payments, time-specific obligations with their deadlines, and expected inbound receipts with a confidence marker. Keep those strictly distinguishable from settled events in both the data model and the interface, because blending known events with expectations produces a number nobody can defend during an incident. That separation is the same discipline that keeps a position distinct from a forecast in the [real-time treasury platform](https://digiqt.com/blog/real-time-treasury-platform/).

## How should stress scenarios be implemented?

As replayable transformations of real days, so results are explainable by pointing to affected flows.

Take a real day's event stream and apply a defined transformation: delay all inbound receipts by two hours, remove the largest counterparty's payments, withdraw a credit line, or combine several. Then recompute the peak and see whether available resources would have covered it. Because the scenario is a transformation of real data rather than a synthetic model, the result can be explained to a board or a supervisor by naming the flows that caused it. Keep scenario definitions versioned, run them on a schedule against recent days rather than once a year, and store results so trend deterioration is visible. The Basel Committee's framework pairs the monitoring tools with stress scenarios for exactly this reason, and the supervisory expectation to manage contingent funding obligations sits in its broader liquidity risk principles.

> **Running intraday stress once a year against synthetic assumptions?**
>
> [Talk to Digiqt about replayable liquidity stress testing](https://digiqt.com/contact-us/)

## How should alerting work so treasury can actually act?

Thresholds agreed with treasury, delivered to a named on-call role, with escalation to someone who can move money.

An intraday monitoring platform that only produces reports is an expensive archive. Define thresholds on projected peak usage against available resources, on time-specific obligations approaching their deadline without funding in place, and on throughput falling behind the expected profile for that hour. Route those alerts to a named role rather than a shared inbox, and make the escalation path end at someone with authority to draw a line or move funds. Review alert quality monthly, tracking how many alerts led to action, because a platform generating alerts nobody acts on will be muted within a quarter. The monitoring and alerting discipline here is the same one set out in this guide to observability for core systems.

## How do you keep regulatory reporting reproducible?

Immutable event snapshots, versioned calculation logic, and stored submissions with full lineage.

Anything submitted to a supervisor must be reconstructable later from the data as it stood, including any corrections that arrived afterwards. Snapshot the event set used for a submission, version the calculation logic as an artefact, store the submitted figures, and retain lineage from every reported number back to the underlying payments. Then provide a decomposition that explains movement between reporting periods, because the first question after an unusual figure is always what changed. Building this once removes the annual scramble that follows every supervisory query.

## How does this connect to positioning, payments, and pricing?

It consumes the payment estate's events, complements the positioning platform, and supplies evidence for internal pricing.

The event stream comes from your payment platforms, which is why a consolidated [payment hub](https://digiqt.com/blog/payment-hub-architecture/) makes intraday monitoring dramatically cheaper: one normalised event stream instead of five bespoke extracts. The positioning platform answers where cash is now and where it is heading, while monitoring answers how much liquidity the day consumed and how close you came to the edge. On instant rails the two converge, because continuous settlement means peak usage can occur at any hour, as covered in [instant payment liquidity management](https://digiqt.com/blog/instant-payment-liquidity-management/). And the observed intraday cost of holding buffers is exactly the evidence a [funds transfer pricing engine](https://digiqt.com/blog/funds-transfer-pricing-engine/) needs to charge contingent liquidity honestly rather than by assumption.

## How should delivery be phased?

Event capture first, then peak and throughput, then reporting, then stress and alerting.

| Phase | Duration | Deliverable |
|---|---|---|
| Event capture and timestamp quality | 3 to 4 months | Timestamped event stream from payment systems, provenance audit |
| Resources and credit lines | 2 to 3 months | Available intraday liquidity including collateral and facilities |
| Peak and throughput computation | 1 to 2 months | Replay engine, per-currency and per-account results |
| Supervisory reporting | 2 to 3 months | Automated returns with snapshots, versioning, and lineage |
| Stress scenarios | 1 to 2 months | Replayable transformations, scheduled runs, trend reporting |
| Treasury alerting | 1 to 2 months | Thresholds, on-call routing, escalation, alert quality review |

Automating the supervisory return before the timestamp quality work is done produces a faster route to a number you cannot defend. Fix the data first even though it is the least visible phase.

## Which metrics prove the platform is working?

Timestamp completeness, feed lag, manual effort per reporting cycle, alert action rate, and stress coverage.

Track the share of liquidity-affecting events arriving with a trustworthy event-time timestamp, because that number caps everything else. Measure feed lag per source so treasury knows how current the view is. Report the manual hours consumed per supervisory reporting cycle and drive it toward zero, since that is the clearest cost saving and the easiest to defend in a business case. Watch alert action rate rather than alert volume. And measure stress coverage, meaning how many scenarios run on a defined schedule against recent real days, since a scenario library that is never run tells you nothing about today.

Intraday liquidity monitoring is one of the few regulatory obligations that produces something operationally valuable when built properly. The banks that get both are the ones that treated it as a data engineering problem about timestamps rather than a reporting problem about templates.

## Frequently Asked Questions

### What does intraday liquidity monitoring actually measure?

How much liquidity a bank uses and has available at every point in the day, including peak usage, available resources, payment timing, and throughput, rather than a single end-of-day balance.

### What do supervisors expect banks to report?

The Basel Committee set out seven intraday liquidity monitoring tools with defined stress scenarios and a reporting regime, with monthly reporting for internationally active banks from January 2015.

### Why can't the regulatory report and the treasury dashboard be separate systems?

They can, and it is a mistake. Two systems produce two answers from the same day, and the reconciliation between them becomes a permanent piece of work nobody owns.

### Which single data field matters most?

The timestamp on every payment and balance movement. Without accurate timing you can compute a daily total but not a peak, and the peak is the whole point.

### What is peak net negative position?

The largest cumulative shortfall between payments made and payments received during the day, which determines how much intraday liquidity you actually needed rather than what you used on average.

### How should stress scenarios be modelled?

As replayable transformations of a real day's data, such as delayed inbound receipts or a counterparty failure, so results are explainable by pointing to the specific flows affected.

### How real time does monitoring need to be?

Treasury needs minutes to act, so build the pipeline for near real time and let regulatory reporting run from the same data on its own cycle.

### What is the biggest implementation obstacle?

Sourcing accurate timestamps and credit line data from systems that were built to report daily totals, which is a data engineering problem rather than an analytics one.

## Sources

- [BCBS, Monitoring tools for intraday liquidity management](https://www.bis.org/publ/bcbs248.htm)
- [BCBS, Principles for Sound Liquidity Risk Management and Supervision](https://www.bis.org/publ/bcbs144.htm)
- [CPMI, Developments in retail fast payments and implications for RTGS systems](https://www.bis.org/cpmi/publ/d201.htm)

Intraday Liquidity Monitoring Systems for Treasury and Regulators

Let Digiqt design a real time treasury platform that gives your treasury team a position they can trust intraday.

See Your Position While You Can Still Act On It

# Seeing the Bank's Cash Position While It Still Matters

Most bank treasury functions can tell you exactly what the cash position was yesterday and roughly what it is now. That was a workable arrangement when money moved on business-day cycles and the only thing that happened overnight was interest accrual.

It stopped being workable when settlement became continuous. A position assembled from files that arrive at cut-off times cannot support a decision at 11 a.m., let alone at 11 p.m. on a Sunday, and the gap between what treasury sees and what is actually happening is now where funding errors and unnecessary buffers live. Building a real time treasury platform is mostly about closing that gap honestly, including being explicit about the places where it cannot be closed.

## Why is a daily cash position no longer good enough?

Because outflows became continuous while funding windows did not, so a stale position can be wrong by more than your buffer.

The asymmetry is the whole problem. Payments leave continuously on instant rails, card settlement and collateral calls arrive on their own schedules, and the wholesale funding market that fixes a shortfall keeps conventional hours. A position computed once or twice a day was a reasonable approximation of a slow system. It is a poor approximation of a fast one, and the cost of that approximation shows up as excess buffer that nobody can justify precisely.

### What changed on the outflow side?

Continuous settlement removed the overnight pause that daily positioning quietly relied on.

Instant rails operate on a full calendar. The FedNow Service, for example, runs a 24-hour business day on every day of the week including weekends and holidays. That means the balance you are managing changes while your reporting stack is idle, and any process anchored to an end-of-day snapshot is measuring a system that no longer stops. Treasury platforms designed around that snapshot inherit its blind spots regardless of how modern the interface is.

### Which decisions does a stale position break?

Funding size and timing, intraday borrowing, sweep decisions, and the judgment call on whether to fund at all.

If the position is hours old, every decision built on it gets padded for uncertainty. Treasury funds more than necessary because the alternative is a shortfall, borrows earlier than needed, and sweeps conservatively. None of those is visibly wrong, which is why the cost stays hidden: it appears as a slightly larger buffer and slightly worse net interest income rather than as an incident. The same dynamic appears wherever a control depends on data that arrives late, which is the argument in this analysis of [building earlier cash forecasts when reporting lags](https://digiqt.com/blog/intraday-liquidity-monitoring/).

> **Funding decisions padded because nobody trusts the intraday number?**
>
> [Talk to Digiqt about a treasury data and positioning review](https://digiqt.com/contact-us/)

## What does a real-time position require architecturally?

A consolidated event-based view of every account, with source, timestamp, and confidence attached to each observation.

Coverage and latency differ by source, and a platform that pretends otherwise produces a confident number that is quietly wrong. Model the differences explicitly instead.

| Data source | Typical latency | Coverage | Reliability concern |
|---|---|---|---|
| Your own payment platform events | Seconds | Complete for your flows | None if the event stream is durable |
| Intraday reporting from account holders | Minutes to hours | Varies by institution and product | Gaps, differing formats, missing intraday support |
| Settlement and clearing confirmations | Minutes to end of cycle | Complete but late | Amounts may differ from authorisation |
| Internal transfers between entities | Seconds if instrumented | Often invisible | Frequently the largest blind spot |
| Card and scheme settlement | Daily | Complete | Netted, so intraday detail is unavailable |
| Collateral and margin movements | Event-driven | Complete but bursty | Large values arriving with little notice |

### Why is the account balance feed the hard part?

Because you depend on other institutions to report, and their coverage and timeliness are outside your control.

Some account-holding institutions provide rich intraday reporting, some provide it for certain products only, and some provide an end-of-day statement and nothing else. You cannot engineer your way past that, so the platform must represent each account's reporting capability as data: expected update frequency, last observation time, and staleness threshold. Then surface staleness in the interface rather than smoothing over it, because a treasurer who knows a figure is four hours old makes a better decision than one shown a single confident total. Improving coverage becomes a relationship conversation with a technical specification attached, which is a far more productive framing than a complaint.

### What is the difference between a balance, a position, and a forecast?

A balance is reported, a position is computed from observations plus known unsettled items, and a forecast is projected.

Keep the three separate in the data model, in the interface, and in the vocabulary your teams use. The position engine should be deterministic: given the same observations, it always yields the same number, and it can explain which observations produced it. The forecast is a different artefact with confidence attached and no authority over the position. Institutions that blend them end up unable to answer the only question that matters during an incident, which is whether a number is something they know or something they predicted. Building this on a stream rather than a nightly load is what makes the distinction operationally possible, and the ingestion patterns in this guide to a data warehouse with real-time ingestion transfer directly.

## How should the position engine handle imperfect data?

By storing immutable observations and recomputing the position as a function of them, never by overwriting.

Late data, corrections, and duplicates are normal. Store each observation with its source, its timestamp, the time you received it, and its type, then compute the position from the observation set. That makes a correction a new observation rather than a destructive update, lets you reconstruct what you believed at any past moment, and gives you a defensible answer when someone asks why a decision looked right at the time. It also makes reconciliation between your computed position and the eventual statement a routine automated check rather than an investigation, which is the same discipline behind [continuous payment reconciliation](https://digiqt.com/blog/nostro-vostro-reconciliation-automation/).

## How should intraday monitoring and forecasting work?

Short-horizon projection driven by calendar, known obligations, and observed intraday patterns, reported alongside supervisory indicators.

The Basel Committee's framework for intraday liquidity sets out seven monitoring tools together with stress scenarios and a reporting regime, with monthly reporting for internationally active banks having started in January 2015. Those measures are a useful design brief regardless of whether they apply to you directly, because they encode what supervisors consider a complete intraday picture: peak usage, available intraday liquidity, throughput, and timing of payments. Build the platform so those measures fall out of the data model natively rather than being assembled quarterly by an analyst, and you get both compliance reporting and genuinely useful operational metrics from the same source.

### Which forecast horizon actually matters?

The next few hours and the next few days, not the next quarter.

Intraday treasury is a nowcast problem. What treasury needs is the projected low point today, the expected position at the next cut-off, and the position across the coming weekend, including known obligations, calendar effects such as paydays and month end, and observed drain rates. Long-horizon forecasting belongs in planning and asset liability work, where it connects to the interest rate and behavioural modelling covered in [ALM and IRRBB system design](https://digiqt.com/blog/alm-irrbb-system/). Keeping the two apart prevents a planning model from being pressed into service for a decision it was never built to support.

> **Reporting supervisory intraday measures by hand every month?**
>
> [Talk to Digiqt about automating intraday liquidity monitoring](https://digiqt.com/contact-us/)

## How do you make the platform usable by treasury rather than impressive to engineering?

By designing for one screen that answers today, with alerting that reaches a person who can act.

Treasury teams do not want a data platform, they want the answer to three questions: where am I now, where will I be at the next decision point, and what needs my attention. Build the primary view around those, show staleness and confidence honestly, and make drill-down available without making it necessary. Then design alerting around thresholds treasury actually agreed, delivered to a named on-call role rather than to a shared mailbox, with escalation to someone who has authority to move money. An alert that arrives in an inbox nobody reads overnight is not a control, and the response-path thinking behind [instant payment liquidity management](https://digiqt.com/blog/instant-payment-liquidity-management/) applies directly to how those thresholds should escalate.

## What controls belong inside the platform?

Threshold alerting, limit monitoring, four-eyes on manual adjustments, and a full audit trail of every position input.

Any manual adjustment to a position should be a recorded, attributed, reversible entry with a reason code, not an edit. Limits by counterparty, currency, and entity should be monitored continuously rather than checked at end of day, and breaches should alert rather than appear in a report. Every input to the position needs lineage back to its source observation, because during an incident the first question is always where a number came from, and the second is who changed it. The regulatory dimension of that requirement is set out in this guide to [data lineage and audit trails](https://digiqt.com/blog/audit-ready-ci-cd-financial/). Counterparty exposure deserves the same continuous treatment, for the reasons described in [counterparty credit in real time](https://digiqt.com/blog/counterparty-credit-risk-system/).

## How should delivery be phased?

Consolidated view first, then automation of feeds, then forecasting, then optimisation.

| Phase | Duration | Deliverable |
|---|---|---|
| Consolidated today view | 2 to 3 months | All accounts in one view with source, timestamp, and staleness |
| Feed automation and coverage | 2 to 4 months | Intraday feeds where available, event ingestion from internal payment platforms |
| Position engine hardening | 2 to 3 months | Immutable observations, recomputation, reconciliation to statements |
| Intraday monitoring and alerting | 1 to 2 months | Supervisory measures, thresholds, on-call alerting |
| Short-horizon forecasting | 2 to 3 months | Nowcast with confidence, calendar effects, weekend projection |
| Optimisation | Ongoing | Sweep automation, funding recommendations, buffer reduction |

Resist the temptation to start with forecasting, which is the phase everyone wants to demo. A treasury team with a trustworthy consolidated view of today and no forecast is in a far better position than one with a sophisticated forecast built on feeds nobody has validated.

## Which metrics prove the platform is working?

Position accuracy against eventual statements, feed timeliness and coverage, buffer reduction, and alert quality.

Measure position accuracy by comparing the computed intraday position with the eventual reported balance and tracking the error distribution, not just the average. Report feed coverage as the share of balances received intraday and feed timeliness as observation lag per source, because those two numbers explain most accuracy problems. Track the buffer treasury holds and the trend, since a genuine improvement in visibility should let it fall while incidents stay at zero. And review alert quality honestly: alerts per week, share that led to an action, and time from alert to action. A platform generating alerts nobody acts on is producing noise with a dashboard attached.

The value of a real-time treasury platform is not the real-time part. It is that a treasurer can finally distinguish what the bank knows from what it assumes, and size decisions to the first rather than the second.

## Frequently Asked Questions

### Why is a daily cash position no longer sufficient?

Because outflows now happen continuously on instant rails while funding windows have not expanded proportionally. A position that is hours old can be wrong by more than your buffer.

### What is the difference between a balance, a position, and a forecast?

A balance is what an account holder reports, a position is your best current view including known unsettled items, and a forecast projects future movement. Conflating them is the most common design error.

### Where does real-time position data actually come from?

Intraday reporting from account-holding institutions, your own payment platform events, settlement confirmations, and internal transfers. Coverage and latency differ by source, which the model must represent.

### What do supervisors expect banks to monitor intraday?

The Basel Committee set out seven intraday liquidity monitoring tools with stress scenarios and monthly reporting for internationally active banks, so build the platform to produce those measures natively.

### How do you handle late or corrected balance data?

Store every observation with its source and timestamp, never overwrite, and recompute the position as a function of observations so a correction reprices history without destroying the audit trail.

### Should the platform hold the forecast model or just the data?

Both, but separately. Keep the position engine deterministic and auditable, and treat forecasting as a distinct component whose outputs are labelled as projections with confidence attached.

### How real time does the position need to be?

Fast enough to act on, which in practice means minutes for balances and seconds for your own payment events, with staleness shown explicitly wherever a feed lags.

### What is the fastest way to deliver value?

Start with a single consolidated view of today across all accounts with staleness flags. Most treasury teams gain more from that than from any forecasting sophistication added later.

## Sources

- [BCBS, Monitoring tools for intraday liquidity management](https://www.bis.org/publ/bcbs248.htm)
- [Federal Reserve, FedNow Service additional questions and answers](https://www.federalreserve.gov/paymentsystems/fednow-additional-questions-and-answers.htm)
- [CPMI, Developments in retail fast payments and implications for RTGS systems](https://www.bis.org/cpmi/publ/d201.htm)

Posts tagged with#Treasury

Funds Transfer Pricing Engine Design That Reflects Real Economics

Intraday Liquidity Monitoring Systems for Treasury and Regulators

Real Time Treasury Platform Design for Bank Cash Positioning

Our Offices