Finance & BankingWorking group kick-off
Finance & Banking working group
A shared language for property finance data
You bring the domain knowledge. OPDA turns it into a model the group can understand, challenge and improve.
No ontology skillsNo graph toolsNo AI adoption required
Questions are welcome throughout
Ontology strategist · Agentic engineer
Hello, I’m
Henrik Pettersen
Ontologies · standards · working systemsHuman judgement stays in control
I turn specialist knowledge into shared models, international standards and working systems. Today, agentic engineering helps me do that faster—without outsourcing judgement.
For this working group
Professional servicessparklingideas.co.uk↗ You bring the Finance and Banking knowledge. I turn your resources, discussions and feedback into reviewable model candidates, schemas and a website.
What I bring to OPDAShared meaning, engineered.
25 years working with ontologies. Connecting specialist knowledge, international standards and production systems.
One continuous practiceFrom expert knowledge to working standards.
Agentic engineering Accelerates the whole loop Evidence in · challenged drafts out · people decide
Working-group orientation
What this first meeting is for
Set the context
Why OPDA is convening the Finance and Banking group, the problem it addresses and how it fits the wider programme.
Present the approach
How existing work will inform domain-led modelling, with distinct contexts connected through interoperability.
Make the model accessible
A plain-language introduction to data models and ontologies—and how familiar schemas and forms can be generated from them.
Show the path ahead
How shared resources become published model candidates, and how the group will review and improve them.
This is an orientation and presentation, with questions welcome throughout—not a live modelling workshop.
Different domains, valid local meanings
Meaning changes across bounded contexts
A property does not need one universal definition. Each domain can describe what matters locally; explicit mappings carry information across the boundary.
↔ ↔ ↔ ↔
Local meaningClear boundariesExplicit mappingsShared identifiersTraceable sources
Continuity with a better source of meaning
Evolution, not replacement
What carries forward
- JSON Schemas and examples
- Schema-derived ontology and mappings
- Glossary, dictionary and validation
- Website and implementation experience
Evidence, traceability, tests and compatibility inputs.
Schema-led derivation→Domain-led, evidence-up modelling
What changes
- Practitioners become the authority for meaning
- Each bounded context receives equal focus
- Differences are mapped rather than flattened
- Review happens through readable website drafts
Bottom-up domain precision, held together by explicit interoperability.
Start with the basics
What is a data model?
An agreed map of the important business things, what they mean, how they fit together and the rules that apply.
Before choosing a file format, agree what the information means.
A familiar view
Forms and schemas organise data as a tree
A tree is excellent for one workflow, form or exchange contract: every item has a chosen place and path.
Mortgage application
one chosen shape→
{
"applicant": { … },
"mortgage": {
"purpose": "purchase",
"property": {
"address": "14 Oak Road",
"estimatedValue": 425000
}
},
"evidence": [ … ]
}The tree answers: “Where does this value go in this particular message or form?”
The connected view
An ontology connects knowledge as a graph
The same concepts can participate in several relationships without being trapped inside one document path.
Applicantapplies forMortgageis secured againstProperty
EvidencesupportsIncome assertionis aboutApplicant
What is it?How is it related?Who asserted it?When was it true?Which rule applies?
The graph answers: “What does this mean, and how can it connect safely to other information?”
Complementary, not competing
Same knowledge, different views
Electronic form
Applicant details
Mortgage request
Property details
Supporting documents
JSON tree
$.applicant$.mortgage$.mortgage.property$.evidence[]Ontology graph
ApplicantMortgagePropertyEvidence
A governed source, familiar views
You do not need to work with the graph
You reviewDefinitions · examples · relationships · rules
Governed meaningOntologyconnected graph
MappingsGeneratorsTemplatesTests
Familiar outputsJSON SchemasForms & APIsWebsitePDF & MarkdownValidationIntegrations
The ontology supplies governed meaning. Tested transformations produce the useful formats.
Precision without fragmentation
Why separate domain models?
“Property” can legitimately mean something different in each context. Mappings make those differences explicit.
In this contextProperty
MappingsSmall common boundaryShared identifiers & provenance
The aim is not competing truths. It is local precision plus an explicit translation at every boundary.
Programme structure
A governed family of working groups
Each group owns its domain meaning. Selected representatives align what crosses the boundaries.
Selected representatives from every groupInteroperability Working Group
Common boundaryContext mapCross-domain mappingsShared conventions
Aligns boundaries; does not control internal domain meaning.Cross-group alignment
The Interoperability Working Group aligns the boundaries
Selected representatives from every domain and scheme working group agree what must work across boundaries.
MembershipRepresentatives from every groupEach brings its domain’s languageDomain questions return to the owning group
Small common boundary ontology
Only concepts and relationships genuinely required for exchange across multiple contexts.
Context map
Where meaning originates, where information crosses a boundary and which group owns each decision.
Cross-domain mappings
Explicit translations between related local terms, vocabularies, taxonomies, identifiers and relationships.
Shared conventions
Identifiers, provenance, versioning and change conventions where cross-context consistency is required.
Boundary agreements, not domain redesign. Each working group retains authority over its internal meaning.
The semantic content
What this working group defines
Six connected kinds of content describe the same business agreement.
Business glossary
What do practitioners mean by each term?
Data dictionary
Which data elements are recorded, in what form and with what expectations?
Taxonomies
How are concepts organised into broader and narrower meanings?
Controlled vocabularies
Which governed terms, codes and values may be used?
Resources
Which important things and concepts need stable identity and description?
Relationships
How do those resources connect, participate and constrain one another?
Representations for different consumers
What OPDA publishes and generates
One governed agreement, released through formats that people and systems can use.
Ontology in RDF
The machine-readable graph of resources, relationships and constraints.
JSON Schemas
Generated exchange contracts for existing schema and form tooling.
Website · PDF · Markdown
Readable, versioned documentation for review and reuse.
Mapping runtime
A potential runtime for ontology/schema mapping and validation where a deployment needs it.
Every generated artefact needsan explicit mappinga governed templateautomated testsa release status
Questions that expose gaps
One completeness lens, eleven themes
A checklist, not eleven models. Select a theme to reveal the practical question it asks.
Meaning 4 themes
Trust 3 themes
Correctness 2 themes
Exchange 2 themes
Readable, reviewable candidates
The website becomes the working surface
Members review diagrams, terms, definitions, examples and changes—not source code.
Current demonstrationThe present site documents the schema-derived model.
Future candidate surfaceVersioned Finance and Banking drafts, open questions and page-level discussion.
opda.org.uk / finance-and-banking / candidate-0.1
Working-group candidate · 0.1
3 open questions8 sourcesUpdated after feedback
Resource-first modelling
First: share what already exists
The first candidate will be grounded in the materials, language and edge cases the sector already uses.
SchemasElectronic formsStandardsVocabulariesPoliciesGuidanceBusiness rulesWorked examplesRepresentative dataProcess mapsScreenshotsAuthoritative definitionsKnown exceptions
Collection details will follow. Do not send restricted material until the handling route, permissions and access controls have been confirmed.
The modelling loop
Share resources. Discuss a candidate. Repeat.
Participants contribute information that can be shared. Henrik and AI turn it into something concrete for the group to challenge and improve.
Feedback · corrections · new evidence
Discussion feeds the next AI-assisted modelling pass—not a separate report or a final answer.
AI is the drafting accelerator
What AI helps with — and what it cannot decide
Henrik leads the modelling. AI analyses evidence from several perspectives; people remain the source of domain truth and accountability.
- Extract terms, rules and examples
- Compare sources and expose differences
- Propose relationships and candidate definitions
- Find gaps, contradictions and missing evidence
- Incorporate reviewed feedback rapidly
- What is true in Finance and Banking
- Which stakeholder judgement should prevail
- Whether restricted material may be published
- Whether a disputed issue is resolved
- Whether a version is official or approved
Always visibleSourcesUncertaintyDissentAutomated checksChange historyHuman judgement
Participants and vendors do not need to run or adopt AI. AI helps build the ontology; the ontology then gives future AI clearer, governed context.
A visible candidate cycle
Publish, review, revise, repeat
We keep iterating until the group judges the model stable enough to become its first official working-group draft.
→ → →
Still to defineConsensus thresholdDispute resolutionEscalationNormative approval
One hub, clear channel roles
Where each conversation belongs
The exact details will be circulated once each channel is established.
One canonical recordIssue & feedback disposition
AcceptedNeeds evidenceDeferredNot accepted
Do not send restricted material until the agreed handling route has been communicated.
The immediate sequence
What happens after this session
OPDA confirms the route
Maria circulates the collection method, Teams channel and working-group email details.
Members share resources
Existing materials arrive with source, permission and sensitivity information.
Henrik builds candidate 0.1
AI-assisted modelling produces the ontology, schemas, documentation and open questions.
The group reviews
The candidate is published through the working-group review surface, announced in Teams and improved from feedback.
The first ask is simple: when the route arrives, share the resources that best explain how your part of the domain works.
The working-group promise
You bring the knowledge.
OPDA makes it reviewable.
01Share evidence
and domain judgement+02Henrik and AI
prepare candidates+03The group challenges
and improves the meaning
and domain judgement+02Henrik and AI
prepare candidates+03The group challenges
and improves the meaning
No ontology expertise. No AI adoption. Just the knowledge needed to make the model correct.
Questions — then hand back to Maria.
opda.org.uk · Open Property Data Association