In-House Banking: Overview

What is In-House Banking?

In-House Banking (IHB) is a treasury management structure in which a central entity within a corporate group acts as an internal bank for its subsidiaries and affiliates. An IHB isn’t a licensed bank; it’s a governance, process, and technology framework used to manage cash, liquidity, funding, and intercompany positions centrally.

An IHB records all activity, both cash and non-cash movements, between a company's subsidiaries or business units and maintains the outstanding balances in a virtual account.

Key characteristics of an IHB include:

• Interest charges: Interest is applied to IHB balances so that the cost of internal funding is properly accounted for.

• GL entries: General ledger entries are generated for both the parent company and the relevant subsidiary, keeping the books of each entity accurate and up to date.

For example, a parent company may fund its subsidiary's operations by transferring money from its own bank account. When this occurs, the IHB must automatically:

• Track the cash movement

• Calculate the associated interest cost

• Generate the corresponding GL journal entries

This ensures full visibility and accurate accounting of intercompany funding activity across the group.

The core principle is centralization: bringing financial control and visibility together in one place rather than leaving it fragmented across individual subsidiaries. This allows the corporate group to operate more efficiently, with greater oversight and coordination of its financial activities.

How In-House Banking Fits into Your Business

Roles Involved

• Central Treasury: Operates the IHB, sets internal borrowing and investment rates, monitors group liquidity, and manages residual FX exposure.

• Subsidiary Finance Teams: Operate their own real bank accounts, reconcile their Internal Current Account (ICA) statements, and record intercompany balances in their books.

• Accounting and Tax: Own the transfer pricing policy, the chart of accounts used for intercompany postings, and period-end reporting.

About In-House Banking

IHB is typically used by large multinational corporations with multiple subsidiaries operating across multiple countries and currencies. It requires investment in treasury technology, such as a Treasury Management System (TMS), and robust transfer pricing and legal frameworks to operate correctly. In-house banking transforms corporate treasury from a passive cash manager into an active internal financial services provider for the entire group.

Pain Points We Can Help You Overcome

• Surplus cash trapped in one subsidiary while another borrows externally at a higher cost.

• Hundreds of external bank accounts to maintain, fund, and reconcile.

• Manual intercompany balance tracking in spreadsheets, with no audit trail.

• Intercompany interest and GL journals calculated by hand at period end.

• No single view of the group's cash and liquidity position.

Key Benefits

• Reduced external borrowing costs by recycling surplus cash within the group.

• Better visibility and control over the group's overall cash and liquidity position.

• Lower bank fees and FX transaction costs through netting and centralization.

• Improved risk management through centralized FX and interest rate exposure.

• Simplified bank relationships, because the group needs fewer external accounts and counterparties.

• Greater operational efficiency through standardized payment and treasury processes.

In-House Banking vs. Netting

IHB and netting are related and often work together in a centralized treasury model, but they serve different purposes, operate at different scales, and solve different problems.

In-House Banking

An In-House Bank typically operates in a single currency. A central treasury may manage multiple IHBs across different currencies, each representing its own local currency pool. Rather than one global IHB managing all currencies together, the central treasury runs a separate IHB for each currency. For example:

• USD in-house bank for US dollar activity

• GBP in-house bank for British pound activity

• EUR in-house bank for euro activity

Each currency pool operates independently, tracking its own intercompany balances, cash movements, and GL entries in that currency. Central treasury oversees all pools, providing group-wide visibility and control. This structure keeps currency management straightforward: subsidiaries transact with the IHB in their local currency, avoiding unnecessary foreign exchange complexity at the intercompany level.

How Does Netting Differ?

An IHB is the overall framework: the internal bank itself. Netting is a specific mechanism that can exist within or alongside an IHB structure. Netting is an optimization tool: it offsets intercompany payables and receivables so that only the net amount is settled, rather than each gross transaction individually.

For example, Subsidiary A owes Subsidiary B $1,000,000 and Subsidiary B owes Subsidiary A $600,000. Instead of two separate gross payments, only one net payment of $400,000 flows from A to B.

There are two main types of netting:

• Bilateral Netting: Between two entities only.

• Multilateral Netting: Across multiple entities simultaneously, typically run through a central netting center on a fixed cycle, such as monthly.

Real Accounts vs. Virtual Accounts

Two types of accounts work together at the heart of an IHB: physical bank accounts and virtual bank accounts.

• Physical (real) bank accounts are held at external commercial banks. They hold actual cash, have real account numbers, and can send and receive external payments.

• Virtual bank accounts, also known as internal current accounts (ICAs), aren’t held at an external bank. They exist purely as ledger entries within the Ripple Treasury Platform. They track intercompany balances, interest, and settlements between the IHB and its subsidiaries, but can’t directly send or receive external payments.

Without virtual accounts, a large multinational would need hundreds of physical bank accounts across multiple countries, resulting in high costs, complex compliance requirements, and fragmented cash visibility. Virtual accounts consolidate cash into fewer real accounts while still maintaining separate account structures for each entity, improving visibility, reducing costs, and simplifying reconciliation.

Physical accounts hold the real cash; virtual accounts provide the structure and granularity to manage it efficiently.

In-House Banking Workflow

The Ripple Treasury Platform records all activity (physical cash movements, third-party payments and receipts, and non-cash movements) between your subsidiaries, maintaining outstanding balances in a virtual IHB account.

1. Subsidiaries operate their real bank accounts. Each subsidiary maintains a real bank account at a local commercial bank for day-to-day operations such as receiving payments, paying suppliers, and running payroll.

2. End-of-day cash sweep. At the end of each business day, physical balances are swept from each subsidiary's real bank account into a central header account owned by the IHB. There are two sweep structures:

   • Zero Balance Sweeping (ZBA): The subsidiary's account is swept to zero every night. Surplus cash moves up to the header account and any shortfall is automatically funded back.

   • Target Balance Sweeping: The subsidiary retains a defined minimum balance for operational needs and only the surplus above that amount is swept to the header account.

3. The IHB records the movement in the virtual account. When the sweep occurs, real cash moves to the IHB header account at the external bank. At the same time, the IHB posts an entry to the subsidiary's ICA reflecting the same movement. The ICA is purely a ledger entry; no physical cash sits there.

4. The IHB manages pooled cash centrally. With cash consolidated in the header account, the IHB uses surplus funds from cash-rich subsidiaries to fund cash-poor ones, avoiding external borrowing. Any overall surplus may be invested, and external credit facilities are only drawn on if the entire group is in deficit.

5. Funding a subsidiary that needs cash. If a subsidiary requires funding, the IHB instructs the external bank to push funds from the header account into the subsidiary's real account. The subsidiary's ICA is credited at the same time, recording an internal loan from the IHB, and interest begins accruing in line with transfer pricing rules.

6. Interest accrues on virtual account balances. The ICA mirrors a real banking relationship: subsidiaries with debit balances (depositors) earn internal deposit interest, and subsidiaries with credit balances (borrowers) are charged internal loan interest. Rates are set by the IHB treasury team in compliance with transfer pricing and arm's length rules, and are typically accrued daily and settled monthly or quarterly.

7. Intercompany settlements via virtual accounts. When two subsidiaries trade with each other, no real cash needs to move. The IHB debits one subsidiary's ICA and credits the other's as a pure book entry. Real cash only moves externally at the settlement date for any residual amounts.

8. Period-end reconciliation. At month end, each subsidiary receives a virtual account statement from the IHB, similar to a real bank statement, showing all deposits, withdrawals, internal loans, interest, and the closing balance. The subsidiary records the ICA balance as an intercompany receivable or payable on its balance sheet. The IHB then reconciles all ICAs against the real header account balance at the external bank.

As a result:

• Subsidiaries never need to manage their own external borrowing; the IHB manages it centrally.

• Physical cash is maximally consolidated, minimizing idle balances across the group.

• Virtual accounts give subsidiaries full visibility of their position without fragmenting real cash.

• Intercompany settlements are processed as book entries, reducing real payment volumes.

• The group borrows less externally, because internal surpluses fund internal deficits.

In-House Banking Use Cases

The following use cases form the foundation of the IHB configuration and setup in the Ripple Treasury Platform. All use cases generate the required transactions and general ledger journal entries from real cash transactions reported on a bank statement and imported into the Ripple Treasury Platform.

The most important part of a successful IHB implementation is a clear understanding of the company's requirements, including which use cases apply.

Across all use cases, the IHB virtual accounts and GL journal entries are maintained for both the parent and the subsidiary, regardless of whether a real bank statement exists for one or both entities. In some implementations the subsidiary generates its own journal entries for the movement through the virtual IHB accounts, but the parent always maintains the subsidiary's virtual IHB account.

Use Case 1: Bank Statements Imported for Both Parent and Subsidiary

The Ripple Treasury Platform imports external bank statement transactions for both the parent company and the subsidiary. Based on these real cash movements, the IHB virtual accounts are updated and GL journal entries are automatically created for both entities.

This is the most straightforward use case because both real bank accounts are visible within the Ripple Treasury Platform, providing a complete picture of the cash movement on both sides of the intercompany relationship.

Example

The parent transfers $110,000 to Subsidiary A. The Ripple Treasury Platform:

• Imports the bank statement for both entities

• Records the debit on the parent's real and virtual account

• Records the credit on Subsidiary A's real and virtual account

• Generates the corresponding GL journal entries for both with user codes 0191 and 0491.

Use Case 2: Bank Statement Imported for Parent Only

The Ripple Treasury Platform imports the external bank statement for the parent company only. The subsidiary's real bank account isn’t held or visible within the Ripple Treasury Platform. The IHB virtual accounts are still updated and GL journal entries are created for both the parent and the subsidiary.

This use case is common where a subsidiary banks with a local or regional bank that isn’t connected to the Ripple Treasury Platform, or where the subsidiary manages its own banking independently. The parent's bank statement is the trigger for all associated entries.

Example

The parent transfers $110,000 to Subsidiary A and only the parent's bank statement is imported. The Ripple Treasury Platform:

• Records the debit on the parent's real and virtual account

• Based on the transaction details, automatically creates the corresponding virtual account entry

• Generates the corresponding GL journal entries for both with user codes 0191 and 0491.

Use Case 3a: Payment on Behalf Of (POBO)

The parent company makes a payment to a third party on behalf of its subsidiary. The payment flows from the parent's real bank account, but the obligation belongs to the subsidiary. IHB virtual accounts are updated and GL journal entries are created for both the parent and the subsidiary.

Payment on behalf of (POBO) is one of the core value-add services an IHB provides. It allows subsidiaries to avoid maintaining their own external banking relationships for payments, reducing banking costs and simplifying operations across the group.

Example

Subsidiary A owes a supplier $50,000. Rather than Subsidiary A paying directly, the parent company pays the supplier from its own bank account. The Ripple Treasury Platform:

• Records the real cash outflow from the parent's bank account

• Updates the parent's virtual account

• Credits Subsidiary A's ICA to reflect the internal funding provided

• Generates the GL journal entries for both entities

Use Case 3b: Receipt on Behalf Of (ROBO)

The parent company may also receive payments on behalf of its subsidiaries. This occurs when a third-party customer pays the parent company's bank account for an invoice or obligation that belongs to a subsidiary.

Receipt on Behalf Of (ROBO) is useful where subsidiaries don’t maintain their own external bank accounts, or where the group has centralized collections through the IHB to improve cash visibility and reduce banking costs.

Example

Subsidiary A is owed $75,000 by an external customer. The payment is made into the parent company's real bank account instead. The Ripple Treasury Platform:

• Records the real cash inflow

• Updates the parent's virtual account

• Debits Subsidiary A's ICA

• Generates the GL journal entries for both entities

Use Case 4: Non-Cash Movements

Not all intercompany activity involves the physical movement of cash. Non-cash movements are recorded through the IHB virtual accounts and the GL without any corresponding real bank transaction. These are pure book entries that reflect financial obligations or transfers between entities within the group.

Common examples of non-cash movements include:

• Margins: Intercompany margin calls or adjustments between entities.

• Dividends: Dividends declared by a subsidiary and owed to the parent, recorded as an intercompany obligation before any cash settlement occurs.

• Equity Contributions: Capital injections from the parent to a subsidiary, recorded as an equity movement rather than a cash transfer.

• Royalties: Fees charged by one entity to another for the use of intellectual property, trademarks, or other assets.

• Intercompany Recharges: Shared service costs, management fees, or overhead allocations charged from the parent or a shared services center to subsidiaries.

Example

The parent charges Subsidiary A a monthly management fee of $20,000. No cash moves immediately. The Ripple Treasury Platform:

• Records a credit to Subsidiary A's ICA

• Records a debit to the parent's ICA

• Generates the corresponding GL entries for both entities

• The balance is settled in cash at an agreed future date.

Copyright 2026 Ripple Labs Inc.