SWIFT Code BNPAFRPP

You need to programmatically confirm that SWIFT code BNPAFRPP points to the correct institution and branch before releasing an international payment or accepting a beneficiary during onboarding. By the end of this article you’ll be able to validate BNPAFRPP against BankDataStack’s SWIFT endpoint, parse the returned bank, branch, and country fields, and wire this check into your payment, KYC, or fraud-defense workflow.

What BNPAFRPP Represents and Why It Matters

BNPAFRPP is a SWIFT/BIC identifying BNP-Paribas SA in Paris, France. SWIFT codes are used in cross-border messaging and settlement to route funds to the correct financial institution and often a specific branch. An incorrect or stale SWIFT code can lead to rejections, delays, or misrouted funds, which increases operational cost and customer support load.

In production payment flows, you should validate the SWIFT/BIC before initiating a transfer or before saving a beneficiary record. This limits rework, prevents failed international wires, and reduces false positives in sanctions and compliance checks that rely on bank metadata (country, city, branch) present in the validation response.

SWIFT/BIC Format Essentials

SWIFT/BIC codes are either 8 or 11 characters:

• Bank code: 4 letters (e.g., BNPA)
• Country code: 2 letters (e.g., FR)
• Location code: 2 letters or digits (e.g., PP)
• Branch code (optional): 3 letters or digits (not present in BNPAFRPP)

BNPAFRPP is an 8-character code, which typically refers to a primary office (often the head office). SWIFT/BICs do not have a check digit like IBANs or ABA routing numbers; instead, validation focuses on structural correctness and authoritative lookups for institution, country, and branch data.

Endpoint and Authentication

Use the SWIFT validation endpoint over HTTPS with a POST request and your API key in the X-API-Key header. The base URL and method are:

• POST https://www.bankdatastack.com/api/v1/swift/validate
• Header: X-API-Key: YOUR_API_KEY
• Body: JSON with the swift field set to the code you want to validate

You can find the full API reference in the Documentation, and you can start a 7-day trial on the Starter plan ($49.99/mo) to get an API key.

Copy-Paste cURL for BNPAFRPP

The request below validates BNPAFRPP and returns the issuing bank, city, and country as JSON. Replace YOUR_API_KEY with your actual key.

curl -X POST "https://www.bankdatastack.com/api/v1/swift/validate" -H "X-API-Key: YOUR_API_KEY" -H "Content-Type: application/json" -d '{"swift":"BNPAFRPP"}'

Python Example: Validating BNPAFRPP in a Payment Flow

This Python snippet wraps the same request, then extracts fields you typically persist in a beneficiary record or use for routing logic and compliance checks.

import json
import sys
import requests

API_KEY = "YOUR_API_KEY"
URL = "https://www.bankdatastack.com/api/v1/swift/validate"

def validate_swift(swift_code: str) -> dict:
headers = {
"X-API-Key": API_KEY,
"Content-Type": "application/json"
}
payload = {"swift": swift_code}
resp = requests.post(URL, headers=headers, json=payload, timeout=10)
# Raise for HTTP status errors (4xx/5xx). Handle gracefully in production.
resp.raise_for_status()
return resp.json()

def upsert_beneficiary_bank(swift_code: str):
result = validate_swift(swift_code)
status = result.get("status")
if status != "success":
# Decide whether to block onboarding or flag for manual review.
raise ValueError(f"SWIFT validation failed: {result}")

data = result.get("data", {})
# Extract normalized attributes you might store
normalized = {
"swiftCode": data.get("swiftCode"),
"bank": data.get("bank"),
"branch": data.get("branch"),
"city": data.get("city"),
"address": data.get("address"),
"postCode": data.get("postCode"),
"country": data.get("country"),
"countryCode": data.get("countryCode"),
# Fields from breakdown may inform heuristics or UI hints
"bankCode": data.get("breakdown", {}).get("bankCode"),
"locationCode": data.get("breakdown", {}).get("locationCode")
}

# Example decision: block if country is embargoed; here we just print.
print(json.dumps(normalized, indent=2))

if __name__ == "__main__":
try:
upsert_beneficiary_bank("BNPAFRPP")
except Exception as e:
print(f"Error: {e}", file=sys.stderr)
sys.exit(1)

Realistic JSON Response and Field Usage

The following is the live-format response block for BNPAFRPP. Your integration should consume these fields as described immediately after.

{
    "status": "success",
    "message": "SWIFT code BNPAFRPP is valid",
    "data": {
        "swiftCode": "BNPAFRPP",
        "bank": "BNP-PARIBAS SA (FORMERLY BANQUE NATIONALE DE PARIS S.A.)",
        "city": "Paris",
        "branch": "Head Office",
        "address": "BOULEVARD DES ITALIENS 16 PARIS 75009 PARIS 75009 FRANCE",
        "postCode": "75009",
        "country": "France",
        "countryCode": "FR",
        "breakdown": {
            "swiftCode": "BNPAFRPP",
            "bankCode": "BNPA",
            "countryCode": "FR",
            "locationCode": "PP",
            "codeStatus": null,
            "branchCode": null
        }
    }
}

How to use these fields:

• data.swiftCode: Echo of the validated SWIFT; store as your canonical SWIFT/BIC for the beneficiary.
• data.bank: Institution legal/trade name; display to users for confirmation and store for reference.
• data.city, data.country, data.countryCode: Useful for country-level screening, currency routing rules, and experience personalization.
• data.branch and data.address: Provide higher-resolution location context; show to back-office reviewers or in customer confirmation screens.
• data.breakdown.bankCode, locationCode: Enable format-aware checks (e.g., bank vs. location segments) and internal analytics.

Integrating SWIFT Validation in Your Flows

1) Beneficiary Onboarding

When a user adds a new recipient with SWIFT BNPAFRPP, call the validate endpoint, show the resolved bank and country for confirmation, and store the response. If the response is a valid success, proceed to save the beneficiary. If the response indicates an invalid or unknown code, block the submission or request correction.

2) Payment Initiation

On payment submission to a recipient already in your system, check the cached validation result for BNPAFRPP. If your cache is missing or stale, refresh it via the endpoint before queuing the payment. Ensure compatible currency/corridor rules are applied using the countryCode returned (e.g., FR).

3) Risk and Compliance

Leverage the returned country, city, and branch to power rule-based alerts or to prefill forms for screening systems. The countryCode aligns well with sanctions-list checks and travel-rule data-sharing where applicable.

Handling Not Found and Other Edge Cases

When a SWIFT code is not recognized or is structurally invalid, the API will not return a successful validation. Treat such results as hard failures at user input time. In back-office tooling, you can allow save-for-review while blocking outbound settlement until a valid SWIFT is provided.

Also consider:

• Empty or malformed input: check length (8 or 11) and character set client-side before calling the API to reduce request volume.
• Branch-specific codes: if a user provides an 11-character BIC but the system only recognizes the 8-character head-office form, allow fallback UX that suggests the 8-character code (like BNPAFRPP) after validation.

Caching Strategy and Data Freshness

Reference bank metadata changes infrequently, but not never. Cache successful validations keyed by SWIFT code. Reasonable TTLs depend on your risk tolerance and update cadence; many teams choose on the order of days or weeks. Always invalidate on user edits, and refresh for payment execution if your cached record is older than your policy threshold.

Store only what you need for your workflow: the SWIFT, the normalized bank name, and country data are commonly sufficient. Avoid persisting entire raw payloads if you don’t need them; it makes schema evolution easier and minimizes sensitive data footprint.

Where SWIFT Fits Alongside IBAN, Routing Numbers, and BINs

Developers often validate multiple identifiers on the same screen (e.g., bank identifier, account identifier, and card BIN). While this article focuses on BNPAFRPP, the table below places SWIFT in context with other identifiers you may validate using BankDataStack endpoints. Note: The United States does not use IBAN.

Security note: never store full card numbers in your systems. A BIN refers only to the first digits used to identify the issuer and sometimes product type. For banking, store only what you need (e.g., masked account numbers and validated bank identifiers).

Putting It Together: A Minimal BNPAFRPP Validation Flow

Below is a recommended sequence for a production-grade integration centered on BNPAFRPP:

1. User enters SWIFT code in your onboarding or payment form.
2. Client performs basic format checks (8 or 11 characters, uppercase letters/digits).
3. Backend calls POST /api/v1/swift/validate with the provided code and your X-API-Key.
4. If status is success, display the bank, city, and country for user confirmation and persist the normalized attributes; if not, present a corrective hint.
5. Before executing a payment, refresh the validation if your cache is stale per policy.
6. Log the validation outcome and retain minimal fields for audit and reconciliation.

Testing and Fixtures

To verify your integration logic without touching live payments, exercise both valid and invalid paths in your development environment. Use a known-good SWIFT like BNPAFRPP during happy-path testing and simulate failures by sending malformed codes (wrong length or characters) in unit tests. For parallel validation logic, you can also test other banking identifiers in separate flows (for example, US routing numbers like 021000021 or IBANs like GB82WEST12345698765432) using their respective endpoints, keeping in mind that the USA does not use IBAN.

Error Handling, Timeouts, and Retries

Set a reasonable HTTP client timeout (for example, 10 seconds in the Python sample) and implement a small, capped retry policy for transient issues like network hiccups. Do not retry on deterministic input errors (e.g., structurally invalid SWIFT). If your service depends on upstream availability for customer-facing forms, consider a graceful degradation path: allow saving a draft but block payment initiation until validation succeeds.

Operational Tips That Save Time

• Normalize casing: store SWIFT codes uppercase and trim whitespace before sending.
• Mask and minimize: never store more identifier data than necessary for your use case.
• Observability: log request IDs and outcome fields (status, swiftCode, countryCode) to trace payment issues quickly.
• Idempotency: for repeated validations of the same input within a short window, prefer your cache instead of repeated API calls.
• UX feedback: echo back the resolved bank name and country to reduce user input mistakes.

Getting Access

You can start with a 7-day trial on the Starter plan ($49.99/mo) and integrate the SWIFT, IBAN, routing, and BIN validators into your app. Visit Register to create an API key, then review the Documentation for request/response details and usage notes.

FAQ

Is BNPAFRPP an 8- or 11-character SWIFT code?
BNPAFRPP is an 8-character SWIFT/BIC, typically representing the head office. Some banks also have 11-character branch-specific BICs.

Can I send a payment with only a SWIFT code?
You generally need both the SWIFT/BIC (bank identifier) and the beneficiary’s account number or IBAN (for IBAN countries). The SWIFT alone identifies the institution and branch, not the specific account.

How should I handle a “not found” or invalid SWIFT?
Block submission or mark for manual review. Do not proceed to payment initiation until a valid SWIFT is provided and validated.

How often should I revalidate BNPAFRPP or other SWIFT codes?
Cache results and refresh them based on your policy (e.g., after a set TTL or before executing a high-value transfer). Bank reference data changes are infrequent but possible.

Does the USA use IBAN?
No. The United States does not use IBAN. Use US routing numbers (ABA) for domestic transfers and SWIFT/BIC for cross-border transfers involving US banks.

If you’re ready to validate BNPAFRPP and other banking identifiers in your payment flows, get your API key now: Register.