Services overview¶

GIB exposes the full breadth of U.S. money-movement (ACH, wires, checks, and book transfers) through one API that gives you deep visibility and operational control. We don't abstract the rails: you work with the same objects, files, and state transitions banks themselves use. We surface the complexity when it matters, guide you when you need it, and never hide the ball.

Each rail behaves differently in terms of timing, error handling, settlement, and operational expectations. ACH is batch-based and exception-driven. Wires settle in real time and carry extensive structured data. Checks flow through Image Cash Letter processes with strict file formats. Book transfers move funds inside GIB and facilitate ledgering across both core and virtual accounts. No matter the rail, GIB provides consistent, granular eventing so you always know what is happening with every transfer.

To support modern platform-banking models, GIB also offers flexible account structures, from standalone DDAs to virtual accounts under an FBO arrangement, so you can design products that meet your reconciliation, segregation, and regulatory needs. All accounts behave as real-time ledgers within GIB's system, and all inbound/outbound transfers (ACH, wire, or check) ultimately credit or debit those accounts.

At a high level:

• ACH provides broad, low-cost U.S. funds movement with predictable batch processing windows and exception-based returns.
• Wires enable high-value domestic and international transfers using the Federal Reserve's interbank settlement service and SWIFT, with strict ISO 20022 formatting and immediate settlement.
• Checks (ICL) allow programmatic deposit of image-based checks using Federal Reserve ICL rules.
• Book Transfers move money between accounts within your program before initiating external payments.
• Accounts & Virtual Accounts give you the ledgering model to map customers, flows, and sub-entities cleanly to the underlying rails.

Taken together, these primitives let you design any payments experience, from standard disbursements to complex multi-party wallet flows, while maintaining full transparency into the mechanics of how funds move through the U.S. financial system.

Each page in this section describes one rail or service: what it is, what operations it exposes, the lifecycle of a transaction on it, the timing windows, the failure modes, and links to the relevant concepts and API operations. If you're new to GIB, start with Core Concepts for the data model; it's the same model used across every rail.

The rails¶

For submission cutoffs, settlement timing, and processing windows on every rail, see Timing & cutoffs.

Cashing checks as a licensed MSB? You capture checks at the counter, deposit via ICL, and record the parties. See Check cashing (MSB transactions).

Account services¶

How to read each page¶

Every service page follows the same structure:

1. What it is: a one-paragraph plain-language description of the rail or service
2. When to use it: the use cases that fit; the use cases that don't
3. Operations: the API endpoints, with links to the API reference
4. Lifecycle: state transitions for transactions on this rail (links to Transactions for the underlying state model)
5. Timing & cutoffs: each service page links out to the central Timing & cutoffs
6. Failure modes & returns: what can go wrong; link to Returns and Automated Returns (both concepts)
7. Related concepts: links to relevant pages in Core Concepts

Cross-cutting expectations¶

These apply on every rail. Read once, then assume:

• Submissions are accepted 24/7. Settlement happens during each rail's processing window. See the central Timing & cutoffs.
• Idempotency is your responsibility. For every POST that creates a resource, populate the external_key field in the request body. See Idempotency.
• OFAC screening and BSA monitoring run on every entry. See Subtransactions.
• Webhooks deliver every state transition. See Webhooks. For events you must act on regardless of webhook status, see Notifications.
• Subtransactions de-nest bulk flows. If your program bundles end-user payments into a single rail Transaction (cross-border remittance, mass payouts, payroll), link a Subtransaction per underlying sender-to-beneficiary pair so the true parties remain visible to BSA / OFAC / Travel Rule compliance.
• Errors share a common shape. See Errors for the response schema and full exception-class catalog.
• Rate limits apply at the WAF layer. Requests from any single IP that exceed 5000 in a rolling 5-minute window are blocked by AWS WAF before reaching the API; no error body is returned, the request is dropped. See Security → Rate limits.

API reference¶

The full operation catalog is at the API reference. Each service page below links directly to the operations relevant to that rail.