iso-compliant is a *technology service* — a deterministic ISO 20022 builder, parser, and validator API. It is not a Payment Service Provider (PSP), not a payment institution (PI), not an e-money institution (EMI), and not regulated under PSD2, the EU Funds Transfer Regulation, FinCEN, or any equivalent regime.
The distinction matters because the regulatory perimeter follows the *holding of customer funds* and the *settlement of payment instructions*. iso-compliant never touches funds — every byte the API emits is an XML file that the customer's corporate-banking channel then transports to the customer's bank. The bank is the regulated PSP; the customer is the regulated corporate; iso-compliant is the file-format compiler in between.
Concretely this means iso-compliant does not need a licence to operate in any of its target jurisdictions. The customer's existing bank relationship and existing corporate-channel agreement are the only regulatory dependencies; iso-compliant slots in alongside them.
The data-protection regime is separate and is in scope: customer-supplied data (beneficiary names, IBANs, addresses) is personal data under GDPR / Swiss FADP / UK GDPR, processed under a controller-to-processor agreement (the DPA at compliance/DPA.md). PII is logged minimally, retained per the tenant's residency selection, and never sold or shared.
For customers whose internal compliance regime requires a regulated counterparty (some banks' "API-third-party-provider" lists require a PSD2 AISP or PISP licence): iso-compliant does not qualify and would not, since its function is upstream of the regulated boundary. The customer's bank's API team needs to acknowledge this carve-out at vendor onboarding.