Companies that issue debit cards to their employees for business-related expenses soon find that keeping track of all those account balances is complicated. Each card account must be loaded—and then frequently reloaded—with an appropriate amount of funds, and then to see how much has been spent and how much remains, the balances from dozens, hundreds, or even thousands of accounts must be totaled. This laborious process provides a mere snapshot that quickly goes out of date, and so the totaling must be repeated.
Galileo's Real-Time Funding (RTF) solution removes this accounting complexity by providing one central account that contains all of the funds for multiple card accounts. When a card is used to make a purchase, Galileo automatically transfers the purchase amount from the central account to the card account in real time. When an amount is reversed back onto the card, Galileo automatically transfers the funds back into the central account.
With this arrangement, a company only has to check the balance of the central account to see how many funds remain, while at the same time separate transaction records for each individual card are also available.
For individual cardholders, the purchasing experience is the same as with a conventional payment card: the real-time funds transfer happens so quickly that authorization time is not noticeably affected. Card transactions are denied only if the central funding account has insufficient funds or if the purchase violates velocity, merchant type, or other limits on the individual card.
For a similar solution using credit limits for charge cards, see <a href="doc:about-corporate-credit" target="_blank">About Corporate Credit</a>.
### Use case 1
A corporation issues three types of cards to its employees, depending on the employee's role and responsibilities. Each department has its own central account, and the monthly budget for the departments is deposited into each central account from another corporate account. For example, the Sales department receives $100,000 per month in its central account, and all of the Sales employees have cards that are tied to that central account. Some employees have a card with a weekly limit of $200 at office supply stores, others have a card with a $500 weekly limit that can be used at a wider number of stores, and the executives have cards with no limits.
Every time one of the cards is used to make a purchase, the card draws on the central account. The department regularly checks the balance of the central account to ensure that they're staying within budget, and at any time they can get an itemized list of what each card spent and where.
### Use case 2
A family has three children who are old enough to learn how to handle money. They set up a central allowance account and issue a card to each child. The cards have different spending limits depending on the age of the child as well as limits on the merchants where the cards are valid. The parents can set a hard monthly limit on the central fund—once it's gone, it's gone—or they can decide to add funds as needed from another family account.
## How it works
The issuer sets up a central account, called an _RTF funding account_, that contains the funds for all of the cards and then creates _RTF spending accounts_ with cards that are connected to the RTF funding account. The RTF spending accounts all have a 0.00 balance, and for this example, the RTF funding account contains 1000.00. When a cardholder uses a card to make a $50 purchase, the sequence of events is as follows:
The merchant sends an authorization request to Galileo for –50.00.
Galileo checks the available balance of the RTF funding account. There are sufficient funds.
Galileo moves 50.00 from the RTF funding account into the RTF spending account. The RTF funding account now has an available balance of 950.00 and the RTF spending account has an available balance of 50.00. Because the transfer was triggered by an authorization request, the 50.00 is locked and cannot be spent on another transaction.
Galileo approves the authorization request and places a 50.00 hold on the RTF spending account, so the available balance on the RTF spending account is 0.00 again.
A few days later, when the –50.00 settlement arrives, Galileo reverses the 50.00 hold and posts –50.00 to the spending account. The available balance for the RTF spending account is still 0.00.
Likewise, if the RTF spending account receives a merchant credit or reversal, the funds are posted to the spending account, and Galileo immediately moves the amount back into the RTF funding account.
See <a href="page:real-time-funding-transaction-examples" target="_blank">Real-Time Funding Transaction Examples</a> for example ledger entries.
## Comparison with other methods
Galileo offers two methods to transfer funds to cards at the time of authorization:
#### Real-time transfers
You perform <a href="doc:authorization-controller-api#real-time-transfers" target="_blank">real-time transfers</a> using the Auth API—logic on your side determines whether funds should be transferred for a given transaction. Real-time transfers can be performed on any debit account. There is no special account setup needed except for maintaining a funding account for the transfers, and the funding account is a conventional account.
#### Real-time funding
Real-time funding requires that special account types be set up. You create RTF funding accounts and RTF spending accounts with cards. With this method, funds are transferred into or out of the spending account for all transactions at all times.
Galileo offers two real-time funding methods:
#### Real-time funding
RTF spending accounts draw on a central RTF funding account at the time of authorization. The spending accounts are debit accounts that maintain a balance of 0.00 at all times.
#### Corporate credit
Corporate credit is structured similarly to RTF, but the spending cards have credit BINs instead of debit, and the funding account has a credit limit that the spending cards all use. See the <a href="doc:corporate-credit" target="_blank">Corporate Credit</a> guide for more information.
## RTF account characteristics
Galileo has created two product categories: RTF funding and RTF spending.
### RTF funding accounts
An RTF funding product has these characteristics:
Thousands of connections with RTF spending accounts
ACH credits and debits, both incoming and outgoing
Connections to RTF spending accounts with different product IDs
Follows these rules for product-switching:
An account can be product-switched, but only to another RTF funding product.
Cannot switch from an RTF funding product to a non-RTF funding product or vice-versa.
Does not support:
Galileo KYC/CIP process
Velocity, MCC, or merchant ID authorization controls at the product or account level
Cannot be a secondary account or have secondary accounts.
### RTF spending accounts
An RTF spending product has these characteristics:
Is a debit-type product.
Can be a <a href="doc:choose-a-card-strategy#physical-cards" target="_blank">physical card</a>, <a href="doc:choose-a-card-strategy#virtual-cards" target="_blank">virtual card</a>, or <a href="doc:choose-a-card-strategy#digital-first-cards" target="_blank">Digital First</a> card
Maintains a 0.00 available balance at all times.
Can be associated with only one RTF funding account.
Cannot be moved to another RTF funding account.
Does not share a balance with the RTF funding account or other RTF spending accounts.
Conventional card transactions, except ATM program fees and balance inquiries
Cashback, at the program manager's discretion
Velocity, MCC, and merchant ID <a href="doc:about-account-level-auth-controls" target="_blank">authorization controls</a> at the product and account levels
The Galileo KYC/CIP process. Whether you need to run KYC/CIP to create a spending account depends on your bank's requirements.
Secondary accounts such as savings or overdraft
Does not support
Real-time ACH transactions
Follows these rules for product-switching:
An account can be product-switched, but only to another RTF spending product.
Cannot switch from an RTF spending product to a non-RTF spending product or vice-versa.
You can create different RTF spending products according to the card types that you want to issue to cardholders. For example, you can create an RTF spending product with a virtual card and another with a physical card, or you can create card products with different spending limits, and all of these card accounts can be associated with the same RTF funding account.
The linkage between RTF funding accounts and RTF spending accounts is created at the account level, during spending-account creation. There is no back-end setting to link an RTF funding product to RTF spending products.
## Creating RTF accounts
See <a href="doc:creating-real-time-funding-accounts" target="_blank">Creating Real-Time Funding Accounts</a> for instructions.
## Managing RTF accounts
See <a href="doc:creating-real-time-funding-accounts#managing-real-time-funding" target="_blank">Managing Real-Time Funding</a> in _Creating Real-Time Funding Accounts_ for instructions.
## Migrating existing accounts to RTF accounts
Ask Galileo for advice on how to proceed. Do not attempt to use product switching to convert non-RTF accounts into RTF accounts.