Open Property Data Association
Smart Property Data Trust Framework
Become a member Join a working group

    Chapter 5 — Security, Risk and Fraud Management

    The first chapter circulated to OPDA, and the one with a live deadline. It is also the chapter where the scheme-operator / data-standard distinction matters most — because almost all of it is scheme-operator territory, and reading it otherwise would saddle SPDTF with obligations a data standard structurally cannot meet.

    Review and input due Friday 24 July 2026

    DBT is also running a Call for Evidence on this chapter: "any key research, standards, frameworks, or reports you believe we should consider", and "any evidence of materials specifically relevant to Chapter 5".

    The five DBT positions

    1. Build on recognised security standards. A baseline of OIDC FAPI, OAuth 2.0, ISO/IEC 27001/2, NIST CSF, NCSC CAF — "or demonstrate that an equivalent approach provides comparable levels of security, interoperability and assurance."
    2. Security assurance should be continuous, not point-in-time. "Accreditation alone should not be relied upon as evidence that participants remain trustworthy." Conformance testing, monitoring, periodic reassessment, and mechanisms to suspend or restrict.
    3. Trust should be dynamic. Machine- and human-readable trust signals: suspension status, dynamic risk scoring, security incident notifications, accreditation status changes, credential validity, recent assurance outcomes.
    4. Rapid, proportionate incident response. Suspend or restrict participants, revoke credentials, isolate services, share threat intelligence — covering emerging threats: synthetic identities, deepfake impersonation, automated fraud and AI-assisted social engineering.
    5. Clear, consistent user support during incidents. Users should understand whether they are affected, what happened, what they must do, and who is resolving it.

    The chapter also sets out a seven-step process (define the risk landscape → identify trust and assurance requirements → minimum security controls → fraud management framework → incident management → test interoperability → monitor and improve), each with "suggested outputs", and eight non-prescriptive model clauses (A–H: security-by-design, security assurance, fraud management, incident response, digital verification, information sharing, operational resilience, participant reliance).

    Session 1 — what was discussed

    Held 6 July 2026 on Teams, ahead of the draft's circulation. Attendees spanned DBT, DSIT, OBL, CMA, FCA, ICO and industry (including OPDA). The substance:

    • FAPI-grade security was floated as a potential baseline across future schemes.
    • Onward sharing through unregulated third parties and subcontractors was identified as a major risk.
    • Data provenance, authenticity and traceability were named as prerequisites for trust — with the note that "derived data should retain links to its original source".
    • Liability remains unresolved — who notifies consumers, who resolves issues, where liability sits.

    What this could mean for SPDTF

    This chapter is the clearest demonstration of why the layer separation matters.

    Positions 1, 2, 4 and 5 are not SPDTF modelling obligations

    FAPI, ISO 27001, continuous conformance testing, incident response, user comms during an incident — these are things a scheme operator does at runtime. It is not the job of the SPDTF semantic model to implement a security stack, run conformance testing, or operate incident response. Those are properties of a scheme's runtime, not of its data standard.

    Position 3 is the exception, and it is a real data-standard obligation. "Trust should be dynamic" asks for machine-readable trust signals — participant suspension status, risk scores, incident notifications, accreditation status changes, credential validity. Those are data. Neither the PDTF schema nor its separately derived ontology can currently emit a single one of them: there is no accreditation-status vocabulary, no participant lifecycle state, no incident notice, no risk tier — gap SD12, the only gap on the register with a dated deadline against it.

    If the response says nothing else, it should say this

    Even if SD12 cannot be closed by 24 July, OPDA's Chapter 5 response should name it — acknowledging that Position 3 lands on the data standard, and that the existing evidence does not yet encode those signals. Letting the review pass in silence concedes the point by default.

    Two further items become SPDTF questions from the session minutes rather than the positions:

    • "Derived data should retain links to its original source" — gap SD4, the highest-value gap on the register.
    • Onward-sharing risk — neither the PDTF schema nor its derived ontology can express a fourth-party recipient chain or an obligation that survives onward transfer (gap SD9).

    The tension worth raising with DBT

    The draft self-describes as non-prescriptive — Section 6 calls its clauses "non-prescriptive wording", "flexible formulation rather than a binding requirement". But it names specific technical standards (FAPI, OAuth 2.0, ISO 27001), specific live initiatives (the UK Finance digital verification service, the City of London's Digital Verification Orchestrator), and a fixed list of suggested outputs per step. In practice, "or equivalent" gets judged against the named standard.

    The relevant point for property is not that FAPI is wrong — it is that most of the property industry does not have financial-grade APIs today, and a baseline written to a finance-grade norm risks being exclusionary rather than proportionate. The chapter's own Position 2 supplies the counterweight ("proportionate and risk-based"), and the Preamble prohibits creating unnecessary burdens for SMEs. That is the ground to argue from.

    Comments

    Loading comments…