generated: '2026-09-06'
method: searched
source: >-
  https://accountsiq.github.io/API-Wiki/specifications.html and
  https://accountsiq.github.io/API-Wiki/authentication2.html for protocol claims;
  wsdl/accountsiq-integration-2-0.wsdl for contract-level evidence;
  https://trust.accountsiq.com/ and
  https://www.accountsiq.com/blog/announcing-accountsiqs-iso-27001-information-security-certification
  for the compliance program.
note: >-
  Every entry below is anchored either to a location in the published WSDL or to a page the
  provider serves. Entries the provider does not support are recorded with conforms:false
  rather than omitted, because an absence an integrator can rely on is also information.
conformance:
- id: soap-1.1
  name: SOAP 1.1
  conforms: true
  evidence: >-
    Stated on the specifications page ("AIQ API uses SOAP 1.1") and declared in the contract as
    the wsdl:binding Integration_2_0Soap with the http://schemas.xmlsoap.org/soap/http transport.
  source: https://accountsiq.github.io/API-Wiki/specifications.html
- id: soap-1.2
  name: SOAP 1.2
  conforms: true
  evidence: >-
    A second binding, Integration_2_0Soap12, is declared in the WSDL alongside the SOAP 1.1
    binding, so both envelope versions are served. The docs mention only 1.1; the contract
    carries both.
  source: wsdl/accountsiq-integration-2-0.wsdl
- id: wsdl-1.1
  name: WSDL 1.1
  conforms: true
  evidence: >-
    Both contracts are WSDL 1.1 documents (root wsdl:definitions in the
    http://schemas.xmlsoap.org/wsdl/ namespace), served at ?wsdl on all four regional hosts and
    byte-identical across regions.
  source: https://eu1.accountsiq.com/system/dashboard/integration/integration_2_0.asmx?wsdl
- id: xml-schema-1.0
  name: W3C XML Schema
  conforms: true
  evidence: >-
    The contract embeds a complete XSD with 280 named complexTypes and closed enumerations
    including VisorExceptionCodes (2404 values) and OperationStatus (7 values).
  source: wsdl/accountsiq-integration-2-0.wsdl
- id: oauth2-client-credentials
  name: OAuth 2.0 client credentials grant
  conforms: partial
  evidence: >-
    Integration 2.0 implements a client-credentials exchange with access and refresh tokens
    (TokenGet / TokenRefresh returning TokenGetResponse{AccessToken, RefreshToken}) and the
    provider names it "OAuth 2.0 Client Credentials Flow". It is not RFC 6749 wire-conformant:
    there is no /token endpoint, no application/x-www-form-urlencoded grant_type request, no
    JSON token response, no Authorization: Bearer header and no scope parameter. The grant
    model is OAuth 2.0; the transport is SOAP. A generic OAuth 2.0 client library cannot be
    pointed at it.
  source: https://accountsiq.github.io/API-Wiki/authentication2.html
- id: oidc
  name: OpenID Connect
  conforms: false
  evidence: >-
    No /.well-known/openid-configuration on any of the eight hosts probed (all 404). No id_token
    or userinfo surface in the contract.
- id: rfc9457
  name: RFC 9457 Problem Details
  conforms: false
  evidence: >-
    Not applicable to a SOAP service and not implemented. Errors are returned in-band on the
    WSResult2Of<T> envelope with a typed ErrorCode, not as application/problem+json.
  see: errors/accountsiq-error-codes.yml
- id: soap-fault
  name: SOAP Fault error signalling
  conforms: false
  evidence: >-
    Notable deviation from SOAP convention: the WSDL declares no wsdl:fault on any of the 219
    operations. Failures are reported on the success envelope, so a client that only handles
    SOAP faults will read every failure as a success with a null Result.
  source: wsdl/accountsiq-integration-2-0.wsdl
- id: pagination
  name: Offset pagination
  conforms: partial
  evidence: >-
    skip/limit arguments on GetAllocationsBetweenPaged, GetAllocationsBetweenWithCreationDatePaged
    and GetOrdersByPaged, plus a Skip field on the WSGetXxxByQuery request types. Most list
    operations are unpaged. No cursor pagination.
  see: conventions/accountsiq-conventions.yml
- id: idempotency
  name: Request idempotency
  conforms: false
  evidence: >-
    No idempotency key mechanism of any kind is published or declared in the contract.
  see: conventions/accountsiq-conventions.yml
- id: optimistic-concurrency
  name: Optimistic concurrency control
  conforms: true
  evidence: >-
    RowVersionNumber is carried on mutable entities and a stale value is rejected with the
    OUTDATED_RECORD error code, which is declared in the WSDL enumeration.
  source: wsdl/accountsiq-integration-2-0.wsdl
- id: iso-27001
  name: ISO/IEC 27001 Information Security Management
  conforms: true
  evidence: >-
    Certification announced by AccountsIQ and listed on the Vanta-hosted trust centre at
    trust.accountsiq.com (HTTP 200).
  source: https://www.accountsiq.com/blog/announcing-accountsiqs-iso-27001-information-security-certification
- id: gdpr
  name: EU General Data Protection Regulation
  conforms: true
  evidence: >-
    Listed on the trust centre; AccountsIQ publishes a data protection addendum, a privacy
    statement, a supplier privacy notice and a candidate privacy notice.
  source: https://www.accountsiq.com/legal/accountsiq-data-protection-addendum
- id: soc2
  name: SOC 2
  conforms: unknown
  evidence: >-
    Not found. The trust centre is a Vanta trust report rendered client-side and its document
    list could not be read anonymously (the underlying GraphQL API rejects unsigned requests
    with "Missing signature or signedAt"), so SOC 2 can be neither confirmed nor ruled out from
    the public surface. Recorded as unknown rather than false.
  source: https://trust.accountsiq.com/
domain_standards:
  note: >-
    AccountsIQ operates in accounting and financial management. No domain MESSAGE standard is
    declared anywhere in the contract or the docs: there is no ISO 20022 message type, no
    PEPPOL or EDIFACT e-invoicing envelope, no XBRL taxonomy and no Open Banking / PSD2 surface.
    A search of the WSDL for SEPA returned only substring false positives inside unrelated error
    codes (REPORT_BASEPATH_*, PURCHASEPAYMENT..._BAD_REQUEST) and is explicitly NOT recorded as
    a hit. What the contract does carry is a set of standard financial IDENTIFIER schemes as
    typed, validated fields, which is a weaker but genuine signal and is recorded as such.
  message_standard_declared: false
  identifier_schemes:
  - id: iso-13616-iban
    name: IBAN (ISO 13616)
    present: true
    evidence: >-
      IBAN carried as a bank/beneficiary field and validated in the contract enumeration:
      ACCOUNT_IBAN_IS_TOO_LONG, BENEFICIARY_VALIDATION_MISSING_IBAN,
      BENEFICIARY_VALIDATION_COUNTRY_DOESNT_MATCH_IBAN.
    source: wsdl/accountsiq-integration-2-0.wsdl
  - id: iso-9362-bic
    name: BIC / SWIFT code (ISO 9362)
    present: true
    evidence: >-
      BankSwiftCode and SwiftCode elements in the XSD, with BANK_SWIFT_CODE_IS_NULL,
      BANK_SWIFT_CODE_IS_EMPTY, BANK_SWIFT_CODE_IS_TOO_LONG,
      BENEFICIARY_VALIDATION_COUNTRY_DOESNT_MATCH_SWIFT error codes.
    source: wsdl/accountsiq-integration-2-0.wsdl
  - id: uk-sort-code
    name: UK bank sort code
    present: true
    evidence: BankSortCode and SortCode elements in the XSD.
    source: wsdl/accountsiq-integration-2-0.wsdl
  - id: eu-vat-number
    name: VAT registration number
    present: true
    evidence: >-
      VATRegistrationNumber and VATExemptReference elements, with
      ACCOUNT_VAT_REGISTRATION_NUMBER_IS_TOO_LONG in the error enumeration. A VatReturnID
      element also exists.
    source: wsdl/accountsiq-integration-2-0.wsdl
  regulatory_features:
  - id: uk-mtd-vat
    name: HMRC Making Tax Digital for VAT
    present: true
    surface: product, not API
    evidence: >-
      "VAT with MTD" is listed as a Core-tier product feature on the pricing page. MTD
      submission is performed by the AccountsIQ product against HMRC; it is not exposed as an
      operation on the integration API, and no MTD endpoint appears in the contract.
    source: https://www.accountsiq.com/pricing
compliance_program:
  trust_center: https://trust.accountsiq.com/
  trust_center_platform: Vanta
  certifications:
  - ISO 27001
  - GDPR
  vulnerability_disclosure_published: false
  vdp_note: >-
    No security.txt on any host (all 404), no bug bounty program found on HackerOne, Bugcrowd
    or Intigriti, and no responsible-disclosure page. The trust centre is the only published
    security surface.
  see: security/accountsiq-trust-center.yml