Resources
Search…
Who Regulates Dataswift?
Dataswift, as a UK company, is regulated by the Information Commissioner’s Office UK under registration number ZA244725 as the lead data protection authority globally for Dataswift Services to operate the Dataswift ONE platform and for the management of personal data in the running of its business.Dataswift is also regulated by the Financial Conduct Authority (FCA) in the UK as an account-information-service-provider (AISP) registered to integrate with banking APIs for payment transactions to be acquired by PDA owners.Dataswift is regulated by the HAT Community Foundation (HCF) as a “HAT Platform Provider”, a certified technology provider for the operation of the plafform and the governance of merchant applications.

Regulatory Governance of Dataswift by HAT Community Foundation

Regulatory governance refers to the use of binding rules – including standard-setting, monitoring and sanctioning – to intervene in specific activities. Regulatory governance may also refer to self-regulation. This section articulates specific activities that are governed by Dataswift and the mechanisms through which Dataswift is regulated.

Regulation of the business through Statutory rights of a Guardian Share

HCF holds one guardian share of Dataswift Ltd. As guardian shareholder and regulator, HCF is entitled to guardian share rights over Dataswift including the rights of the guardian shareholder in the Articles and Association, and also ensuring that Dataswift is mission locked and that the board of directors have a fiduciary duty to uphold the mission and purpose of Dataswift, which is personal data exchange for public benefit.

Regulation of platform through Contract

As according to the original ecosystem proposed by the UKRI HAT research project, Dataswift submits it’s operational platform to oversight and regulation by the foundation through a contract where Dataswift pays 2.5% governance levy on all revenues.An overview of the role of the foundation as a regulator is illustrated below.
HCF executes its oversight responsibility through its presence in the Dataswift One Management Committee that meets once a month or whenever required.HCF’s oversight responsibility within the committee includes:
  • Monitoring the performance of the platform and the risk register of applications approved on the platform
  • Escalating the review of a merchant application to HCF Ethics Board
  • Approving changes in controlled artefacts and documents (see below)
  • Exercising veto on application approvals or changes in controlled artefacts and documents (evoking an escalation to the HCF ethics board)
  • Escalating decisions to HCF when necessary
  • Evaluating the metrics on risks from approved merchant applications
  • Mandating an audit of an application and a reassessment of risks under the review protocol
  • Mandating the suspension of an application if risks from the review are above the threshold
Approval of Controlled Artefacts by the Dataswift One Platform Management Committee
The artefacts (set out in the following list) are designated as controlled artefacts that would require the approval of the Platform Management Committee whenever a change in the artefacts impacts on the operating principles. The changes requiring committee approval are:
  1. 1.
    Changes to Dataswift’s standardised review protocols
  2. 2.
    Changes to the open sourced HAT technical code, including its APIs
  3. 3.
    Changes to the platform legal code, including the data rights of PDA owners
  4. 4.
    Changes to the rating standard
  5. 5.
    Changes to the Glossary of Terms and usage of the term “HAT”
  6. 6.
    Changes to the PDA Dashboard/HAT App’s functionality that would impact on:
    1. 1.
      deleting a PDA (to be implemented)
    2. 2.
      downloading a PDA (to be implemented)
    3. 3.
      Ensuring all data within a PDA, their namespaces, applications, tools and data plugs is presented on the PDA dashboard (at least one device platform)
    4. 4.
      Entering and viewing all data within the PDA through his/her owner’s token
    5. 5.
      Being able to view PDA access logs (to be implemented)
    6. 6.
      Disabling/enabling data debits, applications, tools and data plugs
  7. 7.
    Changes to the following designs:
    1. 1.
      standardised UI/UX designs and interactions for PDA Auth (login, signup, password entry and reset) across all apps and websites
    2. 2.
      the format, design and content of the permission screens, consumer law requirements for contract acceptance and the contractual rights of PDA owners.
  8. 8.
    Changes to Platform technical services that:
    1. 1.
      Impacts on a PDA owner’s right to obscure identity if he so wishes, for example, having different identifiers in different folders to verify his/her identity
    2. 2.
      Impacts on sharing by minimising duration, reducing data shared and limiting the purpose of sharing (to be implemented)
    3. 3.
      Impacts on sharing data without identity
    4. 4.
      Impacts on portability through the use of containers
    5. 5.
      Impacts on the ability to switch PDA issuers
    6. 6.
      Impacts on the ability to download and redeploy the PDAs on different cloud systems
    7. 7.
      Impacts on the ability for PDA owners to contract
    8. 8.
      Impacts on the ability to conduct scalable legal data exchanges
    9. 9.
      Impacts on scalable technical data exchanges
    10. 10.
      Impacts on the audibility and immutability event logs to maintain the integrity of source data into the database (to be implemented)
    11. 11.
      Impacts on private/public key management and PDA owner credentials
  9. 9.
    Changes to the following controlled documents