API for SWIFT Code ITAUUS33 – Itaú Unibanco (Glendale, United States)

You need to confirm whether the SWIFT/BIC ITAUUS33 truly maps to Itaú Unibanco in Glendale, United States, and wire funds without a return or delay. By the end of this guide, you’ll be able to validate that SWIFT code programmatically with BankDataStack’s Finance APIs, understand the essential fields you’ll get back, and integrate the check into your cross-border payment or onboarding flow.

What a SWIFT/BIC Is and Why ITAUUS33 Matters for Cross-Border Finance

A SWIFT/BIC is the international identifier used to route cross-border payments to the correct bank. It has 8 or 11 characters: 4 for the bank, 2 for the country, 2 for location, and an optional 3-character branch. For ITAUUS33, “ITAU” is the bank code for Itaú, “US” is the country, and “33” is the location code. Branch codes (positions 9–11) may be absent in an 8-character BIC, which typically refers to a primary office or a generic routing for the institution’s U.S. presence.

Accuracy matters because an incorrect SWIFT code can cause a payment to bounce or be routed to the wrong correspondent, adding days of delay and manual intervention. For a destination like Itaú Unibanco in Glendale, United States, confirming ITAUUS33 upfront prevents retries, reduces returns, and makes your compliance team confident in the instruction you’re about to send.

Validating ITAUUS33 with BankDataStack

BankDataStack provides REST endpoints dedicated to financial identifiers (SWIFT/BIC, IBAN, US routing numbers, and card BINs). The SWIFT Validator API returns the issuing bank, branch, city, and country as normalized JSON you can trust in production. This keeps your finance flows consistent across multiple payout corridors and reduces per-country logic in your app.

When you validate ITAUUS33, you want to assert three things at minimum:

• The identifier is structurally valid for a SWIFT/BIC (length and permitted characters).
• The code exists in current reference data for SWIFT participants.
• The record maps to Itaú Unibanco and a location in Glendale, United States (so you can display this to users and wire correctly).

SWIFT codes do not have a checksum like IBANs. Validation is based on format rules plus a directory lookup. A “not found” outcome means the BIC is not present in BankDataStack’s current reference data, has been deprecated, or was keyed with a typo; do not proceed with a payment when you receive “not found.”

Endpoint Example: Validate SWIFT ITAUUS33

The example below demonstrates a lookup for the BIC ITAUUS33. Replace YOUR_API_KEY with your key. If you don’t have one yet, get started at https://www.bankdatastack.com.

curl -sS \
-G https://www.bankdatastack.com/api/v1/swift/ITAUUS33 \
--data-urlencode "api_key=YOUR_API_KEY"

Illustrative JSON response using the documented fields (bank, branch, city, country):

{
"bank": "Itaú Unibanco S.A.",
"branch": "Glendale",
"city": "Glendale",
"country": "United States"
}

Field usage in a payment flow:

• bank: Display “Itaú Unibanco S.A.” to the user and log it for payment audit trails.
• branch: If present, include in remittance notes or internal routing hints; otherwise rely on bank/city.
• city: Show “Glendale” to confirm the intended receiving location and for internal risk review.
• country: Enforce policy rules (e.g., allowed corridors, FX pair availability, compliance checks for the United States).

Python Example: Inline Validation Before Release to Payment Rails

This Python snippet demonstrates calling the same lookup and handling a not-found outcome safely. The fields below are the minimal set you need to confirm the destination bank and location before constructing the SWIFT MT instruction with your payments provider.

import os
import requests

API_KEY = os.getenv("BANKDATASTACK_API_KEY", "YOUR_API_KEY")
BIC = "ITAUUS33"

url = f"https://www.bankdatastack.com/api/v1/swift/{BIC}"
params = {"api_key": API_KEY}

resp = requests.get(url, params=params, timeout=10)
resp.raise_for_status()
data = resp.json()

# Expected minimal fields per documentation:
# bank, branch, city, country
bank = data.get("bank")
branch = data.get("branch")
city = data.get("city")
country = data.get("country")

if not bank or not country:
# Treat missing critical fields as "not found" or unusable
raise ValueError("SWIFT lookup incomplete; do not proceed with payment.")

print(f"Validated BIC {BIC}: {bank} – {city}, {country}" + (f" (Branch: {branch})" if branch else ""))

# Example: Build a payment confirmation string for your UI or logs
payment_hint = f"Beneficiary bank: {bank}, {city}, {country}"
print(payment_hint)

Where This Fits in Your Finance Workflows

There are two common integration points for SWIFT validation in finance applications:

• Onboarding: When a customer or counterparty adds a bank, you validate ITAUUS33 immediately and show the resolved bank and city back to the user to catch typos in real time.
• Pre-disbursement checks: Right before release, you re-verify the SWIFT code (and account identifier if applicable) to prevent last-minute errors and to log the exact bank metadata used for the transfer.

For example, if your business user selects a U.S.-destination payout and enters ITAUUS33, your UI can display “Itaú Unibanco S.A., Glendale, United States” with a subtle confirmation check. If the lookup fails, block the “Send” button and request a corrected BIC.

Reference and Data Hygiene Details That Save Time

SWIFT Format Validation vs. Directory Lookup

SWIFT/BIC strings have a defined structure (A–Z, 0–9; 8 or 11 characters). Format checks catch obvious errors like wrong length or non-alphanumeric characters. However, because SWIFT does not include a checksum, you still need a directory lookup. BankDataStack’s SWIFT Validator API covers both: a basic format gate and a record resolution that returns bank, branch, city, and country.

Handling “Not Found” Safely

• Treat a “not found” result as a hard stop. Ask the user to recheck the code or contact their bank.
• Log the failed identifier and user session details for anti-fraud analysis and customer support troubleshooting.
• Consider implementing a retry with user confirmation if your UX allows pasting from external sources to reduce input mistakes.

Caching and Refresh Cadence

• Cache positive validations for a sensible TTL (e.g., 24 hours to 30 days) depending on your risk appetite and product SLA. SWIFT directory entries change infrequently, but you should design a periodic refresh.
• Use negative caching for short periods (e.g., minutes to hours) so transient typos don’t live long in your cache.
• Include the BIC in your cache key exactly as provided; normalize to uppercase to avoid duplicate keys.

Card BINs and Data Minimization

If your platform also supports card-based top-ups, remember that a BIN is only the first digits of a card number used for issuer identification. Never store full PANs in your logs, cache, or analytics. Restrict yourself to the BIN and the minimal metadata needed for routing and risk decisions.

How ITAUUS33 Resolves for Itaú Unibanco in Glendale, United States

When you validate ITAUUS33 with BankDataStack, your goal is to map the code to these essentials:

• bank: Itaú Unibanco S.A.
• city: Glendale
• country: United States
• branch: If available, “Glendale” or a specific office label; otherwise it may be blank for a primary office record.

That mapping lets you construct a clean, auditable payment instruction for your cross-border workflow, or to show a user-facing confirmation prior to sending funds. Your compliance and operations teams should log the resolved fields exactly as returned by the API next to the payment order ID.

Comparing Finance Identifiers You May Validate Together

Teams working on cross-border and domestic payouts often validate more than one identifier. Here is a brief comparison to clarify roles in your architecture:

Operational Guidance for Payments Using ITAUUS33

• Before you create a payment order, run a fresh SWIFT validation and store the returned bank, branch, city, and country alongside the transfer record.
• If user input provides both a SWIFT and an IBAN/account number, validate both, and ensure the country context is consistent (e.g., the IBAN’s country should not conflict with the BIC’s country).
• Respect maintenance windows and non-banking days in the destination corridor; while SWIFT messages can be sent anytime, actual posting can be delayed by weekends and local holidays.
• For any “correspondent required” corridors, your PSP or bank may substitute or chain BICs; still validate the beneficiary bank BIC you collect to minimize downstream rejections.

Error Handling Patterns You Can Reuse

• Timeouts: Use short network timeouts for lookups that are performed on user input (e.g., 5–10s) and implement an offline “Try again” flow.
• Idempotency: If multiple form validations occur, cache by BIC and debounce user typing to reduce calls.
• Auditability: Log the input BIC, the resolved bank fields, and your payment order ID so finance ops can reconcile quickly.

Testing Strategy for ITAUUS33

• Happy path: Validate ITAUUS33 and verify you receive Itaú Unibanco S.A. with Glendale, United States.
• Upper/lowercase: Submit it in lowercase and uppercase; normalize to uppercase before lookups to avoid duplicate cache keys.
• Negative cases: Remove characters (7-char string), add symbols (e.g., “ITAUUS33#”), or switch country code to catch errors and confirm your UX blocks submission.

Security and Compliance Notes

• Do not store end-user credentials or API keys client-side. Perform validations server-side and proxy any client requests through your backend.
• Restrict logs to necessary fields (bank, branch, city, country, and the identifier). For card-related flows, only store BINs—never full card numbers or sensitive authentication data.
• Treat all user-provided identifiers as untrusted input; sanitize and validate before using in any downstream payment initiation.

Get an API Key and Start Validating

To start validating SWIFT codes like ITAUUS33, request your key from BankDataStack. With a single REST call returning normalized bank, branch, city, and country, you can protect your finance flows from costly misroutes and rejections. Visit https://www.bankdatastack.com to get an API key and plug the check into your onboarding and payout screens within minutes.

FAQ

Does a SWIFT/BIC like ITAUUS33 include a checksum?
No. SWIFT/BIC validation relies on format rules and directory lookup; there is no checksum like IBAN’s mod-97.

What does “not found” mean in the SWIFT Validator response?
The code is not in the current reference data, is deprecated, or was entered incorrectly. Do not proceed with the payment; prompt the user to correct the identifier.

Should I cache SWIFT validations?
Yes. Cache positive results for a reasonable TTL (e.g., days) and refresh periodically. Use short negative caching to avoid repeated lookups for transient typos.

Can I use the branch field for routing?
Use it as a hint. Many BICs are 8 characters (no explicit branch), and final routing often depends on the PSP or correspondent network. Always validate the core BIC and show the resolved bank and city to users.

Is it safe to store card numbers when I also validate BINs?
No. Only store the BIN and minimal issuer metadata required for routing and risk. Never persist full PANs.