What does the Address to ISO 20022 API do?

It accepts a free-form postal address (and optional country hint) over a REST POST request and returns a structured ISO 20022 PostalAddress object — separated fields for street, building number, postal code, town, country, etc. — along with OpenStreetMap geocoding and confidence metrics.

Banks, payment service providers, fintech companies, e-commerce platforms, and logistics teams who need SEPA-compliant address data, KYC normalization, or accurate delivery addresses without building parsing infrastructure in-house.

Why ISO 20022 instead of free-text addresses?

From November 2025 onward, SEPA credit transfers and direct debits require addresses in ISO 20022 PostalAddress format. Free-text addresses are rejected by SEPA schemes and trigger expensive remediation. ISO 20022 also harmonizes addresses across cross-border payments globally.

How is this different from Google Maps / a geocoder?

Geocoders return latitude / longitude and place data; they do not parse free-form input into structured fields and certainly not into ISO 20022-tagged fields. This API adds the parsing layer, ISO 20022 mapping, country-aware validation, and confidence scores on top of OpenStreetMap geocoding.

Which countries are supported?

Currently UK and European addresses (EEA). Support for other countries is in development.

Which specific countries does the parser cover?

Postal code validation and address normalisation for 47 European jurisdictions. Western Europe: Austria, Belgium, France, Germany, Ireland, Liechtenstein, Luxembourg, Monaco, Netherlands, Switzerland, United Kingdom. Northern Europe: Denmark, Estonia, Faroe Islands (Denmark), Finland, Iceland, Latvia, Lithuania, Norway, Sweden. Southern Europe: Andorra, Azores (Portugal), Cyprus, Greece, Italy, Malta, Portugal, Spain. Central Europe: Czech Republic, Hungary, Poland, Slovakia, Slovenia. Balkans and South-Eastern Europe: Albania, Bosnia and Herzegovina, Bulgaria, Croatia, Kosovo, Montenegro, North Macedonia, Romania, Serbia, Turkey. UK Crown Dependencies: Guernsey, Jersey, Isle of Man, Northern Ireland.

Which languages does the parser recognize?

Native keyword vocabularies for 18 European languages: English (en), German (de), French (fr), Italian (it), Spanish (es), Dutch (nl), Polish (pl), Romanian (ro), Finnish (fi), Swedish (sv), Norwegian (no), Danish (da), Croatian (hr), Slovenian (sl), Czech (cs), Slovak (sk), Hungarian (hu), and Portuguese (pt). The parser uses these to detect language-specific street, room / apartment, floor, and PO-box indicators — for example, "Étage 3", "Postfach 123", "kerros 2", or "lakás 5".

What does a typical response look like?

The response contains an `original_address` echo, a `structured_address` object keyed by ISO 20022 tags (StrtNm, BldgNb, PstCd, TwnNm, Ctry, etc.), an optional `geolocation` with latitude/longitude, a `bldg_exists_on_osm` flag, and a `confidence` object with parsing, geocoding, completeness, and overall scores.

How is this different from — and better than — libpostal?

libpostal is an excellent open-source C library, but it is a self-hosted parsing component, not a managed API. Three concrete differences. (1) Output schema: libpostal emits its own tag set (house_number, road, city, state, etc.) which you must translate yourself into ISO 20022 fields — we emit StrtNm, BldgNb, PstCd, TwnNm, CtrySubDvsn, Ctry, etc. directly, ready for SEPA payloads. (2) Footprint and operations: libpostal needs ~2 GB of resident memory and you operate it yourself; we are a hosted REST API with no infrastructure to run, scale, or patch. (3) Beyond parsing: every response also includes OpenStreetMap geocoding with a `bldg_exists_on_osm` flag, a postcode-centroid coordinate fallback when OSM is silent, country-aware postcode validation against a 2.6M-row database, native keyword recognition in 18 European languages, and a four-part confidence breakdown (parsing, geocoding, completeness, overall) — none of which libpostal provides out of the box. The Senzing-retrained libpostal model improves accuracy versus vanilla libpostal but does not change any of these three structural differences.

When and what fields might be enriched?

Enrichment runs when the parsed postal code is recognised AND the parsed town name fuzzy-matches the expected town for that postal code. It only fills gaps — fields that were already detected in the original input are never overwritten. Three address fields are eligible: TwnLctnNm (town locality, e.g. a London borough), DstrctNm (district, e.g. "Greater London"), and CtrySubDvsn (country subdivision, e.g. "England" or "Bavaria"). Geolocation has its own enrichment path: the API first attempts building-level coordinates, and when no record is found for the address it falls back to the postcode centroid — returned with `level: "postcode"` and a diminished geocoding confidence so a real building hit always ranks higher. If neither the postal code nor the town match succeed, no enrichment is applied and the response reflects only what was present in the input.

What is Address to ISO 20022 API?

Address to ISO 20022 API is a professional REST API service that transforms free-text postal addresses into structured, ISO 20022 compliant formats. Built for financial institutions, payment processors, and businesses that need reliable address normalization at scale.

Core Service: Paid REST API

Our primary offering is a paid REST API that provides enterprise-grade address parsing and normalization services. The API accepts free-text postal addresses in any format and returns structured, ISO 20022 compliant address objects.

What You Get

RESTful API: Simple HTTP endpoints that integrate seamlessly with any application or system
ISO 20022 Compliance: Output addresses in the exact format required for SEPA payments and financial transactions
Real-time Processing: Get normalized addresses in milliseconds with high availability and reliability
Scalable Infrastructure: Handle high-volume address processing with tiered pricing that grows with your needs
Comprehensive Documentation: Complete API documentation with examples, code samples, and integration guides
Geocoding & Validation: Addresses enriched with coordinates and building verification
Confidence Metrics: Detailed confidence scores to help you assess result quality

The API is designed for production use by financial institutions, payment service providers, e-commerce platforms, and any business that processes addresses at scale. With multiple subscription tiers, you can choose the plan that matches your volume and performance requirements.

Free Tier: Quality Assurance & Testing

We offer a free tier to ensure service functionality and quality. This tier allows you to:

Test the service: Evaluate address parsing accuracy and ISO 20022 output quality before committing to a paid plan
Verify integration: Test API integration with your systems and ensure compatibility
Assess confidence metrics: Understand how confidence scores work and determine acceptable thresholds for your use case
Validate functionality: Confirm that the service meets your specific requirements and quality standards
Explore features: Try all API features including single address normalization and batch processing

Free Tier Includes (Pilot):

10,000 API calls per month
Full access to all API features
ISO 20022 compliant output
Geocoding and confidence metrics
Rate limit: 60 requests per minute
Complete API documentation

The free tier is perfect for developers evaluating the service, small projects with low volume needs, or businesses that want to verify quality before scaling up. It provides full functionality with reasonable limits, ensuring you can thoroughly test the service's capabilities.

Enterprise Batch Processing: Custom Solutions

For large customers with high-volume batch processing needs, we offer tailored batch file processing with a custom approach designed specifically for your use case.

Custom Batch Processing Features

Large File Support: Process batch files containing thousands or millions of addresses
Custom Workflows: Tailored processing pipelines designed for your specific requirements
Flexible Formats: Accept input in various formats (CSV, JSON, XML, etc.) and output in your preferred structure
Dedicated Processing: Isolated processing environments for sensitive or high-priority workloads
Priority Support: Direct access to our technical team for custom requirements and optimization
SLA Guarantees: Service level agreements tailored to your processing windows and deadlines
Custom Reporting: Detailed processing reports and analytics specific to your needs

Our custom batch processing service is ideal for:

Financial institutions migrating large address databases to ISO 20022 format
Payment processors processing historical transaction data for compliance
E-commerce platforms normalizing customer address databases
Data providers cleaning and structuring address datasets
Enterprise systems with one-time or periodic bulk processing needs

Each custom batch processing engagement is designed around your specific requirements, data formats, processing volumes, and timeline. We work closely with you to ensure the solution perfectly fits your use case.

Use Cases

SEPA Payments

Convert customer addresses to ISO 20022 format required for SEPA credit transfers and direct debits. Ensure compliance with European payment regulations.

Financial Compliance

Normalize addresses for KYC (Know Your Customer) processes, regulatory reporting, and financial transaction processing.

Address Validation

Validate and standardize addresses in customer databases, reducing delivery failures and improving data quality.

Data Migration

Migrate legacy address data to ISO 20022 format when upgrading payment systems or integrating with new platforms.

Why Choose Our Service?

ISO 20022 Expertise: Built specifically for financial services and payment processing requirements
Multilingual Parsing: Native keyword recognition for 18 European languages — from English and German to Croatian and Hungarian (full list in the FAQ below)
Production-Ready: Enterprise-grade reliability, scalability, and performance
Flexible Pricing: From free tier to enterprise custom solutions, choose what fits your needs
Quality Assurance: Free tier allows you to verify quality before committing
Custom Solutions: Tailored batch processing for large-scale enterprise needs
Comprehensive Support: Detailed documentation, API examples, and responsive support
Continuous Improvement: Regular updates and enhancements based on user feedback

Get Started Today

Start with our free tier to test the service, then scale up to a paid plan as your needs grow. For enterprise batch processing requirements, contact us to discuss a custom solution tailored to your use case.

View Pricing Plans Explore API Documentation Learn Why We Built This

Frequently asked questions

What does the Address to ISO 20022 API do?: It accepts a free-form postal address (and optional country hint) over a REST POST request and returns a structured ISO 20022 PostalAddress object — separated fields for street, building number, postal code, town, country, etc. — along with OpenStreetMap geocoding and confidence metrics.
Who is this API for?: Banks, payment service providers, fintech companies, e-commerce platforms, and logistics teams who need SEPA-compliant address data, KYC normalization, or accurate delivery addresses without building parsing infrastructure in-house.
Why ISO 20022 instead of free-text addresses?: From November 2025 onward, SEPA credit transfers and direct debits require addresses in ISO 20022 PostalAddress format. Free-text addresses are rejected by SEPA schemes and trigger expensive remediation. ISO 20022 also harmonizes addresses across cross-border payments globally.
How is this different from Google Maps / a geocoder?: Geocoders return latitude / longitude and place data; they do not parse free-form input into structured fields and certainly not into ISO 20022-tagged fields. This API adds the parsing layer, ISO 20022 mapping, country-aware validation, and confidence scores on top of OpenStreetMap geocoding.
Which countries are supported?: Currently UK and European addresses (EEA). Support for other countries is in development.
Which specific countries does the parser cover?: Postal code validation and address normalisation for 47 European jurisdictions. Western Europe: Austria, Belgium, France, Germany, Ireland, Liechtenstein, Luxembourg, Monaco, Netherlands, Switzerland, United Kingdom. Northern Europe: Denmark, Estonia, Faroe Islands (Denmark), Finland, Iceland, Latvia, Lithuania, Norway, Sweden. Southern Europe: Andorra, Azores (Portugal), Cyprus, Greece, Italy, Malta, Portugal, Spain. Central Europe: Czech Republic, Hungary, Poland, Slovakia, Slovenia. Balkans and South-Eastern Europe: Albania, Bosnia and Herzegovina, Bulgaria, Croatia, Kosovo, Montenegro, North Macedonia, Romania, Serbia, Turkey. UK Crown Dependencies: Guernsey, Jersey, Isle of Man, Northern Ireland.
Which languages does the parser recognize?: Native keyword vocabularies for 18 European languages: English (en), German (de), French (fr), Italian (it), Spanish (es), Dutch (nl), Polish (pl), Romanian (ro), Finnish (fi), Swedish (sv), Norwegian (no), Danish (da), Croatian (hr), Slovenian (sl), Czech (cs), Slovak (sk), Hungarian (hu), and Portuguese (pt). The parser uses these to detect language-specific street, room / apartment, floor, and PO-box indicators — for example, "Étage 3", "Postfach 123", "kerros 2", or "lakás 5".
What does a typical response look like?: The response contains an `original_address` echo, a `structured_address` object keyed by ISO 20022 tags (StrtNm, BldgNb, PstCd, TwnNm, Ctry, etc.), an optional `geolocation` with latitude/longitude, a `bldg_exists_on_osm` flag, and a `confidence` object with parsing, geocoding, completeness, and overall scores.
How is this different from — and better than — libpostal?: libpostal is an excellent open-source C library, but it is a self-hosted parsing component, not a managed API. Three concrete differences. (1) Output schema: libpostal emits its own tag set (house_number, road, city, state, etc.) which you must translate yourself into ISO 20022 fields — we emit StrtNm, BldgNb, PstCd, TwnNm, CtrySubDvsn, Ctry, etc. directly, ready for SEPA payloads. (2) Footprint and operations: libpostal needs ~2 GB of resident memory and you operate it yourself; we are a hosted REST API with no infrastructure to run, scale, or patch. (3) Beyond parsing: every response also includes OpenStreetMap geocoding with a `bldg_exists_on_osm` flag, a postcode-centroid coordinate fallback when OSM is silent, country-aware postcode validation against a 2.6M-row database, native keyword recognition in 18 European languages, and a four-part confidence breakdown (parsing, geocoding, completeness, overall) — none of which libpostal provides out of the box. The Senzing-retrained libpostal model improves accuracy versus vanilla libpostal but does not change any of these three structural differences.
When and what fields might be enriched?: Enrichment runs when the parsed postal code is recognised AND the parsed town name fuzzy-matches the expected town for that postal code. It only fills gaps — fields that were already detected in the original input are never overwritten. Three address fields are eligible: TwnLctnNm (town locality, e.g. a London borough), DstrctNm (district, e.g. "Greater London"), and CtrySubDvsn (country subdivision, e.g. "England" or "Bavaria"). Geolocation has its own enrichment path: the API first attempts building-level coordinates, and when no record is found for the address it falls back to the postcode centroid — returned with `level: "postcode"` and a diminished geocoding confidence so a real building hit always ranks higher. If neither the postal code nor the town match succeed, no enrichment is applied and the response reflects only what was present in the input.