This page focuses on what is publicly visible about CitiConnect® APIs and related documentation signals, and it separates those signals from what typically requires onboarding validation (entitlements, region scope, commercial terms).
What a banker, treasury user, or implementation team can infer from public material.
Citi publicly shows API discoverability and explicitly links that story to files and pre-built integrations.
Public implementation materials and testing references help teams gauge how much of the journey is documented up front.
Eligibility, pricing, entitlement rules, and region differences should still be treated as onboarding questions.
This page works best as a first-pass view before bank engagement or detailed integration planning.
These categories are described in public CitiConnect® API materials. A Citi press release lists examples of commonly used APIs (balances, payment status, FX rates). Full scope can vary by client segment and geography.
| Category | What it typically enables | Public evidence signal | Confidence |
|---|---|---|---|
| Balance reporting and account information retrieval for treasury reporting and forecasting. | Public CitiConnect® API descriptions include account balance inquiries. | ||
| Payment status, acknowledgements, and workflow visibility for reconciliation and exception handling. | Public CitiConnect® API descriptions include payment status reporting. | ||
| Retrieving FX rates and (where applicable) booking FX contracts for payments and treasury operations. | Public CitiConnect® API descriptions include FX rates and booking FX contracts. | ||
| Payment initiation from ERP/TMS or middleware; often paired with H2H/file for high volume. | Public materials describe API connectivity routes and payments use cases, but product scope can be entitlement-dependent. |
Citi publishes an API Playbook that lists example CitiConnect® APIs and, in some cases, example message formats and region notes. This is useful for discovery, but it is not a substitute for production documentation and entitlements.
| API (public doc name) | What it does (plain English) | Doc-visible notes (formats / scope) | Confidence |
|---|---|---|---|
| Securely connects client systems to Citi’s API services. | Uses OAuth 2.0 (as stated in playbook). | ||
| Retrieves ledger and available balances (treasury reporting/forecasting signal). | Playbook describes a camt.052-based response with balances only (no transactions). | ||
| Initiates payments from client systems (often combined with H2H/file for bulk). | Playbook references ISO XML credit format pain.001.001.03; product scope and rails vary by region/entitlement. | ||
| Tracks payment status (reconciliation-critical) and can push status updates. | Playbook references pain.002.001.03 responses and push notifications; status granularity can vary by rail. | ||
| Requests statements for a period and later retrieves the statement payload. | Playbook references camt.053 end-of-day statements and MT940 (format can vary by client setup). | ||
| Initiates direct debit instructions where supported. | Playbook explicitly notes availability in Australia, Singapore, and Hong Kong; references pain.008.001.02. | ||
| Tracks cross-border payments using SWIFT gpi (monitoring signal). | Playbook lists SWIFT gpi monitoring; implementation details depend on rail/product setup. | ||
| Creates/enables/disables users in CitiDirect BE® (admin signal). | Playbook references CitiDirect BE; validate admin models and audit trails in onboarding. | ||
| Helps systems avoid processing on bank holidays and cutoffs (ops signal). | Playbook references JSON responses; confirm exact branch/country scope. |
Source: Citi: CitiConnect® API Playbook (PDF) (undated). Last verified: Apr 2, 2026.
This section is intentionally neutral. It describes what is visible (or not visible) publicly, without inventing missing features.
Some developer portal content may be JavaScript-rendered and may not be easily indexable for non-logged-in users. If a detail is not visible publicly, it is flagged as requiring validation.
Public materials often do not fully describe client eligibility, required entitlements, or product-by-region availability. Expect these to be clarified during onboarding.
Pricing and commercial terms are typically not disclosed in developer portals. Plan for procurement and contracting work in parallel with technical design.
Public material may reference implementations and testing portals, but end-to-end steps, certification, and operational readiness details are often handled in implementation engagements.
Connectivity options (API, files, SWIFT, ERP integration) are described publicly, but region-level differences may not be fully documented on a single public page. Validate for your market early.
If documentation gaps exist publicly, teams should plan for earlier discovery workshops with the bank and allocate time for entitlement mapping, data mapping, and testing.
Use these to compare discoverability, onboarding visibility, and documentation clarity across banks.
Public developer portal with documentation paths that can be evaluated for clarity and completeness.
financeAI.tech page that compares public portal visibility and limitations across banks in a neutral format.
Graphic-first side-by-side comparison with evidence fields for each category.