Check cashing (MSB transactions)¶

Most programs do not use this flow. The default GIB integration is the main model: Subclients plus Subtransactions over the ACH, wire, and BOOK rails. MSB transactions cover one narrow use case, cashing physical paper checks, described below. The deciding factor is that use case, not your licensure status. If you are not sure whether it applies to you, assume the main model; GIB will confirm during onboarding if the check-cashing flow is the right one for your program.

Programs that cash physical paper checks integrate with GIB through a dedicated, simpler flow that is separate from the main model. There are two pieces:

1. ICL deposits the physical check image through the Federal Reserve under Check 21. This is the money movement.
2. MSB transaction records the parties involved in the check-cashing event. It carries no money. It is the recordkeeping object that lets GIB meet its bank-level due-diligence and BSA obligations on check-cashing activity.

If you cash paper checks as an MSB, you submit both: the ICL to deposit, and the MSB transaction to name the parties.

How this differs from the main model¶

Most GIB programs provision Subclients and move money over ACH, wires, and BOOK transfers. Check-cashing programs do not. They:

• do not create Subclients or Virtual Accounts,
• do not originate ACH,
• integrate through their existing point-of-sale / processor system (the software at the check-cashing counter), which is typically who calls this API, and
• send a looser, mostly-optional field set: only processor_key is strictly required.

In practice the integrator is the POS/processor software provider, not the check casher itself.

When to use it¶

• Your program cashes physical paper checks and deposits them through GIB. This is an MSB activity, hence the name, but what matters is the check-cashing use case, not your licensure status.
• You (or your POS/processor vendor) need to record the parties to each check-cashing event.

If you are any other party running any other flow, including but not limited to fintechs, money transmitters, and anyone GIB has not explicitly directed to use this flow, you do not use MSB transactions; you use the main model. See the Services overview for the right rail and Subtransactions for de-nesting bulk remittance flows.

Deposit tickets for check cashing¶

Your ICL files carry a deposit ticket at the start of each bundle, like every ICL deposit. Check-cashing programs use these values on the ticket:

• Payor bank routing number: 091218461, the GIB routing number for check-cashing customers.
• On-Us: <account number>/123. 123 is the check-cashing deposit tran code.

Operations¶

All operations require an authenticated client user with the matching msbtransaction.* permission.

The parties¶

An MSB transaction names the people and entities in a check-cashing event. Getting these straight is the main thing to understand:

• Maker / payer: the party who wrote the check. For these feeds the name arrives in the payer fields (processor_payer_name, processor_payer_identifier) and the address in the maker_* fields. Often a business, e.g. an employer.
• Payee: who the check is made out to (processor_payee_*). Can be a consumer or a business.
• Conductor: the natural person who physically presents the check at the counter and receives the cash. The conductor is also the endorser who signs the back of the check, so the conductor_* fields are where endorser data goes.

The conductor is usually, but not always, the payee:

• If the payee is a consumer, the conductor/endorser is usually that same person. A payee can also sign the check over to someone else, who then cashes it. In that case the conductor is the person who cashed it, not the payee. Record each in their own fields.
• If the payee is a business, the conductor/endorser is an authorized representative of the business (for example a CEO or other employee authorized to cash checks on its behalf).

GIB uses these party records to meet its due-diligence and BSA recordkeeping responsibilities as the bank. Send what your POS system has; only processor_key is required.

processor_key¶

processor_key is the unique identifier your processor / POS system assigns to the check-cashing transaction. It is not an API key or credential. You copy it in from your own system. (GIB assigns each integrator a processor at onboarding.)

GIB requires processor_key to be unique per company, so it also acts as your idempotency key: resubmitting the same processor_key collides with the existing record instead of creating a duplicate. Use your processor's stable transaction ID, not a value you regenerate.

Field reference¶

Required fields are marked. Everything else is optional; send what you have. Fields with a fixed set of accepted values are marked; those value lists are pending and must be filled before this page is published.

Identity¶

Check details¶

Maker / payer (who wrote the check)¶

Payee (who the check is made out to)¶

Conductor / endorser (the person at the counter)¶

Context and linkage¶

Read-only (returned, not set by you)¶

id, company_id, company_name, create_date_time, update_date_time, create_user_id, update_user_id.

A guide to filling out the data¶

A minimum viable payload is just the required fields:

{
  "processor_key": "PROC-12345",
  "check_amount": 50000
}

In practice, send everything your POS system captures so the party record is complete. A fully populated example:

{
  "processor_key": "PROC-12345",
  "check_cashing_date_time": "2024-02-10T10:30:00.000Z",
  "check_number": "CHK-7890",
  "check_amount": 50000,
  "processor_create_date_time": "2024-02-10T10:30:00.000Z",
  "processor_update_date_time": "2024-02-10T10:30:00.000Z",
  "processor_payer_name": "ABC Company",
  "processor_payer_identifier": "PAYER-456",
  "processor_payee_identifier": "PAYEE-123",
  "processor_payee_name": "John Doe",
  "processor_payee_type": "individual",
  "processor_payee_type_source": "system",
  "location_name": "Main Office",
  "msb_name": "Quick Cash Services"
}

Tips:

• Amounts are cents. A $500.00 check is 50000.
• Datetimes are UTC, Zulu format. Convert local counter time to UTC before sending.
• Reuse your processor's transaction ID for processor_key. Do not regenerate it, or you will create duplicates instead of safe retries.
• Record who actually cashed the check. For a consumer payee this is usually the payee, but not when the check was signed over to someone else. For a business payee it is the authorized representative who cashed the check.
• Batch with create-many if your POS pushes a daily file rather than per-transaction calls.

Related¶

• Check (ICL), the deposit rail that moves the funds
• Transactions, the ICL Transaction state model
• Idempotency, how GIB dedupes submissions
• Security, BSA monitoring and OFAC screening