Security¶

GIB handles money. The platform's security and compliance posture is a first-class concern, and we publish it here so your security, compliance, and procurement teams can review without an NDA call.

If your team has a question this page doesn't answer, contact security@gibank.com.

Reliability¶

Our platform runs on resilient cloud infrastructure with multi-region disaster recovery. We perform regular failover drills. Live status, scheduled maintenance, and incident history are published at status.gibank-api.com.

We employ a Web Application Firewall (WAF) and continuous automated security monitoring. All API traffic is rate-limited (see below).

Rate limits¶

Rate limiting is enforced at the AWS WAF edge, before requests reach the API:

• 5000 requests per 5-minute rolling window, per source IP. Requests over this threshold are blocked by the WAF, not by the application. The WAF returns a generic block response (403) with no API error body — the request is dropped before any handler runs, so the standard {error, exception_class} envelope does not apply.
• The limit is per IP. If you operate behind a fixed egress, all your traffic shares one bucket; if you fan out across many IPs, each IP gets its own bucket.
• The WAF also applies AWS Managed Rules (Common Rule Set, Admin Protection Rule Set), which can block individual requests for SQL-injection, XSS, or admin-path patterns even below the rate threshold.

If you expect sustained traffic above this threshold, contact your GIB onboarding team to discuss adjusting the limit for your program.

Authentication¶

API keys¶

API keys are User-specific. They're created in the dashboard under your User profile. Each User can hold multiple keys for the same Company, useful for separating CI, staging, and production traffic.

When you create a key, you choose:

• An optional expiration (recommend ≤ 90 days for production)
• A list of allowlisted IP addresses (required, see IP allowlisting)
• An optional name for dashboard identification

The full key string is shown once. We store only a hash; if you lose the key, revoke and re-issue.

To use a key, send it in the Authorization header on every request:

Authorization: <your_api_key>

Authorization (RBAC)¶

GIB uses role-based access control. The User holding the API key inherits that User's role; the role determines which endpoints can be called and which resources can be acted on. See Companies & Users → Roles & Permissions.

IP allowlisting¶

All keys must be tied to one or more allowlisted IP addresses or CIDR blocks. Requests from any other source are rejected with 403 ForbiddenError.

• Allowlist your production application's egress IPs, not your office network
• For multi-region deployments, allowlist each region's outbound IP block
• Update the allowlist before deploying to a new region or rotating IPs

You can update the allowlist for any key from the dashboard. Changes take effect within ~30 seconds.

Rotation and revocation¶

Rotate keys at least every 90 days, and immediately on any of:

• Departure of a team member with key access
• Detection of unauthorized usage in webhook traces or audit logs
• Lost device or compromised CI secret

To rotate: create a new key, deploy your service to use it, then revoke the old key. To revoke: open the key in the dashboard and click Revoke. Revocation is immediate.

Compromise response¶

If a key is compromised:

1. Revoke immediately from the dashboard
2. Email security@gibank.com with the key's last four characters and the time of suspected compromise
3. Review the audit log for unauthorized activity
4. We'll assist in reviewing transaction logs and, where possible, recalling pending transactions

Transport security¶

• TLS 1.2 minimum; TLS 1.3 supported and preferred
• HTTP requests are rejected
• HTTP/1.1 keep-alive and HTTP/2 supported and recommended for connection reuse
• Certificate pinning isn't required for general API usage; contact us if your environment requires it

Webhook signature verification¶

Every webhook payload is signed with HMAC-SHA256 using a per-subscription secret. See Webhooks → Authentication & signature verification for the algorithm and a reference implementation.

Data masking¶

To protect sensitive information, certain values are masked with the ✦ symbol. This prevents unintentional exposure when keys with broad permissions are used in low-trust environments (customer support tools, etc.).

Specific permissions are required to view unmasked data, see Companies & Users → Roles & Permissions.

Duplicate detection¶

GIB checks for duplicates on resource creation across multiple endpoints — including Transactions, Subclients, and others. If a matching resource already exists, the API returns 409 ConflictError.

The exact fields used for duplicate detection differ per operation and are documented in each operation's description in the API reference. In general, if external_key is provided the match is key-based; otherwise the API falls back to matching on a combination of core fields specific to that resource type.

For Transactions, the 409 response also includes the X-Duplicate-Transaction-Transfer-Keys header listing the transfer keys of the conflicting transaction(s).

To intentionally retry, include an external_key in the request body — re-submitting the same external_key for the same User returns 409, signalling that the original request was accepted. See Idempotency for the retry pattern, including how to force-submit a legitimate transaction re-run using X-Duplicate-Override-Reason.

Data residency and encryption at rest¶

• Customer data is stored within the United States
• Data at rest is encrypted using AES-256
• Database backups are retained per the program agreement and are also encrypted
• We don't store full PAN/PCI data; payment card data is tokenized via a third-party provider and never held in our database

Vulnerability disclosure¶

We welcome reports of security vulnerabilities. Email security@gibank.com with details. We commit to acknowledging your report within 48 hours and providing a remediation timeline. We don't pursue legal action against good-faith security research conducted under our responsible-disclosure policy.

Certifications and audits¶

Audit reports (SOC 2, penetration tests, others as applicable) are available under NDA, contact compliance@gibank.com.

Breach notification¶

If we confirm a security incident affecting your data, we'll notify the contact on file for your program per our agreement, with a description of the incident, scope, known impact, mitigation steps taken, and a follow-up point of contact.

Related concepts¶

• Companies & Users, User-attributed actions, RBAC, the submission constraint
• Idempotency, safe retries that don't trigger duplicate detection
• Webhooks, signature verification details
• Errors, error response shape including auth/security errors