APIs and endpoints
Each supported SMBC institution has a separate Sandbox endpoint and production endpoint. Use the endpoint for the SMBC institution where the customer’s account is held.
SMBC Bank International plc, London
Sandbox endpoint
https://api.b1f8f05b.compliance.obconnect.io/xs2a/v1
Production endpoint
https://api.e037fa3b.compliance.obconnect.io/xs2a/v1
SMBC Bank EU AG, Frankfurt
Sandbox endpoint
https://api.6bdc8878.compliance.obconnect.io/xs2a/v1
Production endpoint
https://api.84e0a93c.compliance.obconnect.io/xs2a/v1
SMBC Bank EU AG, Paris Branch
Sandbox endpoint
https://api.5be6f3cb.compliance.obconnect.io/xs2a/v1
Production endpoint
https://api.357dc512.compliance.obconnect.io/xs2a/v1
SMBC Düsseldorf Branch
Sandbox endpoint
https://api.93cb1078.compliance.obconnect.io/xs2a/v1
Production endpoint
https://api.a04e7d3d.compliance.obconnect.io/xs2a/v1
SMBC Brussels Branch
Sandbox endpoint
https://api.a5f1400c.compliance.obconnect.io/xs2a/v1
Production endpoint
https://api.ccf5f6c2.compliance.obconnect.io/xs2a/v1
Select the applicable institution and environment before creating a consent. Continue using the same endpoint throughout the lifecycle of the consent and all related account, payment, authorisation and signing-basket resources.
Use the endpoint URLs exactly as published. Do not:
- transfer resources or identifiers between Sandbox and production;
- use a resource created or returned through one institution endpoint with another institution endpoint;
- derive, construct or modify an endpoint URL; or
- add a separate SMBC branch code.
The endpoint URLs shown above are base URLs. Combine the applicable base URL with the operation path defined in the relevant API specification. For example:
Base URL
https://api.b1f8f05b.compliance.obconnect.io/xs2a/v1
Operation path:
/consents
Complete URL
https://api.b1f8f05b.compliance.obconnect.io/xs2a/v1/consents
The API Catalogue is the authoritative source for operation paths, methods, required headers and parameters, request and response schemas, media types, examples and operation-specific errors.
In this guide:
- API Catalogue means the complete collection of the three supplied OpenAPI specifications;
- Consents API Reference means the Consents specification;
- Accounts API Reference means the Accounts specification; and
- Payments API Reference means the Payments specification, including its payment, signing-basket and funds-confirmation operations.
Payment products
Supported payment products and ISO 20022 message versions
pain.001-sepa-credit-transfers
pain.001 request
- Standard SEPA Credit Transfer: pain.001.001.03 or pain.001.001.09.
- SEPA Instant Credit Transfer: pain.001.001.09 with INST.
pain.002 status
- pain.002.001.03 for pain.001.001.03;
- pain.002.001.10 for pain.001.001.09.
Institution availability
- Standard SEPA Credit Transfer: all supported institutions.
- SEPA Instant Credit Transfer: Frankfurt, Paris, Düsseldorf and Brussels only.
pain.001-internal-transfers
pain.001 request
pain.001.001.03
pain.002 status
pain.002.001.03
Institution availability
All supported institutions.
pain.001-swift-transfers
pain.001 request
pain.001.001.03
pain.002 status
pain.002.001.03
Institution availability
All supported institutions.
pain.001-chaps-payments
pain.001 request
pain.001.001.03
pain.002 status
pain.002.001.03
Institution availability
London only.
pain.001-faster-payments
pain.001 request
pain.001.001.03
pain.002 status
pain.002.001.03
Institution availability
London only.
The selected payment-product path, institution endpoint and XML message must form a supported combination. The version of the corresponding pain.002 status response is determined by the version of the original pain.001 payment instruction.
The Payments API Reference and published SMBC ISO 20022 schemas and usage guidance remain authoritative for field-level and product-specific requirements.
ISO 20022 schemas
Use the SMBC SWIFT MyStandards Readiness Portal to view the applicable SMBC usage guidelines, access published schema resources and sample messages, and test XML payloads before submitting them to the API.
A free SWIFT.com account is required. Developers can self-register and then self-join the public SMBC MyStandards community to access the Readiness Portal.
Passing MyStandards validation confirms that the XML payload complies with the applicable schema and usage-guideline checks. It does not confirm that the certificate, consent, account, institution endpoint or payment will be accepted by the API.
Content types
Consents, account lists, account details and balances use JSON as defined in the applicable API Reference.
Account transaction reports are returned as camt.053.001.08 XML and require: Accept: application/xml
Payment initiation requests use the supported pain.001 XML message for the selected payment product.
Payment details are returned as pain.001 XML. Payment status is returned as the corresponding pain.002 XML message.
Use the operation's defined media type and XML namespace, and validate the payment XML against the applicable SMBC schema and usage guidance.
Resource identifiers
Treat Consent IDs, account resource IDs, Payment IDs, authorisation IDs and Basket IDs as opaque API identifiers.
Do not decode them, alter them or construct them from customer-facing account or payment information.
Identifiers remain scoped to the applicable institution and request context. Where relevant, they are also scoped to their parent resource and payment product.
Transaction entry references used for incremental account retrieval are not API resource identifiers.
Dates, pagination and request control
See Consent Journey for consent validity, Accounts Journey for transaction periods, pagination and entryReferenceFrom, and Payment Journey for requested execution dates, payment expiry and idempotent payment creation. See Payment Status Guide for controlled status retrieval.
Rate limits
API requests are subject to the following rate limits per TPP:
- 10 requests per second; and
- 300 requests per minute.
If either limit is exceeded, the API returns HTTP 429 with TOO_MANY_REQUESTS. Reduce the request rate before retrying. Avoid continuous or overlapping requests and apply appropriate retry controls when handling HTTP 429 responses.
Errors and correlation
Use the HTTP status and public error code together.
Journey guidance explains recovery actions where an SMBC-specific journey decision is required. The applicable API Reference defines operation-specific response structures and corrections. Security and Access describes certificate, role and signing failures.
Retain X-Request-ID for correlation.
When an error shows that a certificate, role, consent, resource, product, request format or lifecycle status is invalid, correct the relevant condition before retrying.
For a temporary server or availability error, do not assume that a payment has been rejected or create a duplicate payment solely because the outcome is not yet available.
POST /payments/{payment-product} supports idempotent payment creation using X-Request-ID. A TPP retrying the same payment-creation request after an uncertain outcome must reuse the same X-Request-ID and submit the same request unchanged.
Do not reuse an X-Request-ID to submit a different payment instruction. Do not generate a new X-Request-ID solely because the outcome of the original request was not received, as this may create a separate payment.
Use the response returned for the repeated request and any available Payment ID or status link to continue the existing journey. The Payments API Reference defines the operation-level behaviour and responses.
Retrieve the existing resource or status when the operation and returned information permit this.