Phrased the way we would answer them in a discovery call. No hand-waving on SLAs we haven’t signed; no claims of bank endorsement we don’t have.
Do I need to change anything in my code, or just my data?
Most teams need both, but the data is the bigger lift. The code change is small: replace the <AdrLine> writer in your pain.001 builder with a structured-address writer that populates <StrtNm>, <BldgNb>, <PstCd>, <TwnNm>, <Ctry>. The data change is bigger: your existing customer / vendor / payroll table likely has freeform address strings, and those need to be parsed into structured fields. POST /v1/address/restructure does the parse deterministically and returns a confidence label; route high-confidence results into the new structured columns and queue medium / low for human review.
Will my bank accept files emitted via iso-compliant immediately?
If your bank is on the shipped or in-development tier of our rule-pack registry, yes — the pain.001 we emit is validated against that bank’s IG before it leaves our pipeline. If your bank is on the planned tier or off our registry entirely, we still emit a SWIFT-MX-baseline-compliant file; you should run it through your bank’s test environment first. We will not claim a bank "accepts" us when we have no signed attestation from that bank.
What about banks not in your rule-pack matrix yet?
We ship a SWIFT MX / CBPR+ baseline rule pack that satisfies the structured-address mandate at the SWIFT FINplus layer. If your bank layers additional rules on top — a country-sub-division requirement, an IBAN-country consistency check, a building-name fallback — those overlays may need a bank-specific rule pack. Email engineering with the bank name and your IG link and we will scope it; the standing target is two weeks from IG receipt to shipped rule pack.
How does this work with my existing EBICS/SFTP integration?
iso-compliant emits the pain.001 XML; you submit it through whatever channel your bank requires. The most common pattern: your ERP or scheduler calls POST /v1/iso20022/pain.001, persists the returned XML to disk, then hands it to your existing EBICS T client (e.g., openEBICS, Stetwin) or SFTP uploader. You keep the channel layer; we replace the file-shaping layer. We do not currently emit EBICS frames or hold EBICS bank keys.
What’s the SLA if iso-compliant is part of my payment-emission path?
The Free tier has no SLA — it is for evaluation and low-volume use. The Production tier carries a standard commercial availability commitment with monthly credits for breaches; the exact percentage and credit table are in the order form. For embedded payment-emission paths where iso-compliant sits in the critical path of payroll or supplier runs, talk to engineering about an embedded SLA and a dedicated on-call rotation. We will not commit to numbers on a public page that we haven’t reviewed with you against your traffic profile.
Can I sign up for free first to test?
Yes. The Free tier gives you 100 documents per month — enough to validate every pain.001 / pain.008 emission path you care about and run a UAT against your bank’s test environment. No credit card. No expiry. When you cross the threshold, the API is identical — you change a billing flag, not your integration code.
My ERP vendor told me they’ll ship the structured-address fix in their next release. Should I wait?
Two questions to ask the vendor: (1) what is the actual release date and is it before your next batch run, and (2) does their fix include a one-time backfill of your existing address data, or only new records going forward? If the answer to (1) is "later than your next payroll" or (2) is "new records only", you need a bridge. iso-compliant is a deterministic file-shaping layer in front of your bank — it does not replace the ERP fix, it absorbs the gap until the ERP fix lands and runs against your historical data.
We already passed the bank’s UAT before 2026-11-14. Why are we rejecting now?
Three common reasons. First, some banks ran UAT against a permissive validator and tightened it at the cutover — your test pain.001 passed, your production one doesn’t. Second, UAT often runs with synthetic clean data; production runs against your actual messy customer database. Third, some IGs added per-bank overlays in the final two weeks before the cutover (HSBC’s building-name fallback, Deutsche Bank’s country-sub-division). Pull the pain.002 file, find the AddtlInf or NARR field, and the specific rule violated should be in there.
How is this different from just using my bank’s portal to enter payments manually?
For one-off payments, manual entry is fine. For payroll, supplier batches, or any automated emission path, manual entry is operationally untenable — you lose batching, audit trails, idempotency, and reconciliation. iso-compliant is the file-readiness layer for systems that need to emit pain.001 at scale; the bank portal is the fallback when those systems break.
What happens to our data — do you store the addresses we lint?
The free /address-lint widget on the structured-address page is pure browser-side — no network call, no storage. The /v1/address/restructure API endpoint logs a hash of the input for billing-counter purposes, not the input itself; the structured output is returned and discarded after the response. For full pain.001 emission, the file is persisted (encrypted at rest) for the configured retention window so you can replay or audit; the retention default is 30 days, configurable per workspace.