Business Banking Use Cases

With Galileo's business-to-business (B2B) offerings, you can offer your business clients a variety of solutions to meet their individual needs. The examples in this guide show possible ways to combine Galileo's B2B solutions, and you can devise other combinations as needed.

• Use case 1: Corporate charge cards — How to set up customized card products for different employee levels and fund them with a single credit limit for each department.
• Use case 2: Fleet cards — Using specialized Mastercard BINs to provide enhanced purchase data as well as arranging accounts in a hierarchy for ease of management.

Use case 1: Corporate charge cards

Featuring:

• Corporate Credit
• Account-Level Authorization Controls

Slingback Corporation makes shoes, and it wants to issue charge cards to employees who make purchases on the company's behalf. Slingback has five primary divisions, and every quarter it allocates funds to each division for company-related expenses. Slingback also has identified three types of cardholders within the company: executives, conventional department managers, and inventory managers.

Slingback wants to place limits on the type of spending that each cardholder makes: executives would use their cards when entertaining clients and when traveling, department managers need to purchase software, hardware, and office supplies, and inventory managers have to pay vendors in their supply and distribution chains. Slingback wants to make sure that inventory managers cannot use company funds for entertaining, for example, and that executive cards cannot be used for office supplies. Slingback also wants to place different spending limits on different employees, depending on their seniority and responsibilities. Most of all, Slingback wants a straightforward way to manage these expenses.

In its partnership with Galileo, Slingback uses the Corporate Credit (CC) product to control spending per department, and then it employs Account-Level Authorization Controls (ALCs) to impose limits at a per-employee level.

Setting up the spending cards

According to the three types of buyers, Slingback creates three spending card products:

• Executive card — This card has the most elegant graphic design and card materials to showcase Slingback's brand. By default, these cards can be used at all merchants except for gambling, nor at the merchants that are permitted by the other two card types. There are no spending limits on these cards.
• Department manager card — This card has a standard design on plastic and by default is valid for hardware, software (but not video gaming), office supplies, caterers and bakeries, but not ATMs. The card has a $5000 weekly spending limit.
• Inventory manager card — This card has the same design as the department manager card. It can be used exclusively to purchase goods from suppliers and to pay distributors. Because Slingback knows how often the vendors need to be paid and how much, the card can make 12 purchases per week, and each purchase must be $8000 or less.

📘

Note

If Slingback does not want to manage three products, it can create one product and then impose all limits on a per-employee basis using ALCs.

• See Corporate Credit spending product in the Corporate Credit guide for the characteristics of a CC spending account.

Setting up the departmental accounts

Slingback sets up five CC funding accounts, one for each department, and sets a different credit limit on each account.

Slingback then issues cards to designated employees and links each card to its respective departmental funding account. For example, Sales and Marketing could issue five executive cards and eight department manager cards, whereas Purchasing issues 10 inventory-manager cards and Accounting issues four department-manager cards.

Slingback issues different types of cards according to employee role. Each card draws from the credit limit of the department's funding account.

• See Corporate Credit funding product in the Corporate Credit guide for the characteristics of a CC funding account.
• See Create a Corporate Credit funding account in Creating Corporate Credit Accounts for instructions on creating the departmental credit limit.
• See Create a Corporate Credit spending account in Creating Corporate Credit Accounts for instructions on issuing a card to an employee.

📘

Note

If Slingback wanted to use debit BINs instead of credit BINs, it could use Galileo's Real-Time Funding product, which has a similar structure to the CC solution, except that the central funding account is a debit account with funds that the cards draw from rather than a credit limit.

Tracking spending

At any time during the quarter, the accounting department can see how much available credit each of the five departmental funds has as well as the balance. Because the spending cards always have $0 balance, there is no need to tally the account balances for all of the cards. Instead, Slingback creates an accounting portal that calls Get Balance to display the available credit and balance for each of the five departmental funds, and it has the option to drill down into the individual transfers per funding account or per card using Get All Transaction History. Additionally, Galileo sends raw data files that Slingback feeds into its database to generate reports on card and funding account activity.

Establishing account-level controls

Slingback would like to give the department managers in Product Development a higher spending limit—$7000 per week—and wants to include airlines, hotels, restaurants, and ground transportation as valid merchants.

Velocity ALCs

The product-level weekly velocity control for the department manager card looks like this in the Galileo system:

To increase the weekly amount to 7000, Slingback calls the Get Auth Control endpoint to retrieve the control ID, and then calls Set Account-Level Auth Control for each of the Product Development managers' accounts with these parameters:

• controlId: 1
• amount: 7000
• transactionCount: 20

Optionally, if Slingback wanted to eliminate the transaction count limit for those accounts, it could leave transactionCount empty instead of passing a value.

With these ALCs in place, the Product Development managers can spend up to $7000 per week and other managers can spend only $5000 before transactions are denied. In the case that a manager needs to exceed a limit one time, Slingback can temporarily increase the limit by adding an expiry date to an ALC.

• Read Velocity controls in Designing Authorization Controls for general information about spending controls.
• See Velocity controls in Setting Account-Level Authorization Controls for detailed instructions on how to set a velocity ALC.

MCC ALCs

These are the existing product-level MCC controls for the department manager card:

All MCCs that are not allowed are denied. To add airlines, hotels, restaurants, and ground transportation to some of the accounts, Slingback calls Set Account-Level MCC Controls with mccControls: ['3000-4789', '5812-5814'] andallowDeny: a for each of the Product Development managers' accounts.

• Read MCC controls in Designing Authorization Controls for general information about merchant category controls.
• See MCC controls in Setting Account-Level Authorization Controls for detailed instructions on how to set an ALC.

With these MCC controls in place some department managers can use their cards while traveling and others cannot. If a manager needs to travel one time, Slingback can temporarily add those MCCs to the manager's account by adding an expiry date to the ALC.

Merchant ID controls

Slingback wants to stop the executives in one of its locations from spending at certain entertainment establishments that have proven to be untrustworthy. Slingback has collected three merchant IDs to block. For each of the executive accounts in that location, Slingback calls the Set Account-Level Merchant Control endpoint three times with these parameters:

• merchantId: Merchant ID
• allowDeny: d

With the merchant ID controls in place, the executives cannot use their cards at the untrustworthy establishments. If Slingback wants to restore access to one of the merchant IDs, it can expire or delete the ALC.

• Read Merchant ID controls in Designing Authorization Controls for general information about merchant category controls.
• See Merchant ID controls in Setting Account-Level Authorization Controls for detailed instructions on how to set an ALC.

Use case 2: Fleet cards

Featuring:

• Fleet BINs
• Corporate Hierarchy

Bunting Payments Company specializes in handling fleet cards for small and medium-sized businesses that maintain fleets of vehicles and other equipment. One of its clients, Parcel Delivery, has 10 vans that are driven by a rotating schedule of 15 drivers. Another client, Vista Rentals, lets out landscaping equipment such as sod cutters, trenchers, and mini-excavators.

Bunting issues fleet cards from a specialized Mastercard BIN that provides enhanced information at both authorization and settlement. This information makes it easier for Bunting's clients to track vehicle- and equipment-related expenses and thereby manage those costs.

Driver-issued cards

Parcel Delivery decides to issue a fleet card to each of its drivers, which gives them the flexibility to adjust spend controls per driver according to the drivers' role and years of experience.

With the additional fleet data that the fleet card provides at settlement, Parcel Delivery can track fueling locations per driver and help recommend the best places to get fuel along each route. They can also correlate the vehicle and driver IDs to see who drives which van each day.

Vehicle-issued cards

Vista Rentals wants to issue a fleet card to each piece of equipment, which enables them to track maintenance costs per machine and to limit where each card is used. For example, all cards by default can purchase repairs from the same sources, but one type of equipment may need specialty supplies that the other machines don't need, and the spending limits per equipment type can vary.

To set spending limits as well as merchant category controls, Vista Rentals can use Account-Level Authorization Controls, as described in Use Case 1.

Corporate hierarchy

To organize the accounts of its various clients, Bunting builds a Corporate Hierarchy, which means that for each of its clients Bunting creates a root group and then structures subgroups according to the clients' needs. Parcel Delivery, for example, has two offices, and would like to keep the accounts for each office separate. Vista Rentals, on the other hand, wants to group its accounts by equipment type, so there is one group for sod cutters, another for trenchers, and so on.

For Parcel Delivery, Bunting sets up this hierarchy:

Parcel Delivery organizes its accounts by location.

For Vista Rentals, Bunting sets up this hierarchy, which groups the accounts by equipment type, including groups for the large and small excavators.

Bunting organizes its accounts by equipment type.

Bunting provides a web portal for each of its clients. By using the group ID, Bunting can show the totals for each subgroup and then provide a drill-down to each individual card's activity.

The Bunting web portal leverages corporate hierarchy to organize its clients' accounts.

Some of the screens are populated with data from the Fleet Data RDF, which contains details about each purchase and the stores where the fuel or supplies were purchased. Both Parcel Delivery and Vista Rentals can use this data for inventory management and spending control.