# A Semantic Model for Enhancing Data-Driven Open Banking Services
## 3 Semantic Model
### Methodology  
When defining a new ontology, a good practice is to follow a well-grounded methodology that considers all the required aspects for knowledge domain description. Concretely, the \"Ontology 101 Development Process\" [23] was used, which consists of the following seven steps:  
1. Determine the domain and scope of the ontology. The ontology domain represents the different actors and the information generated in open banking services. More specifically, bank statements and invoice management systems are contextualised to allow for data reconciliation tasks.
2. Consider reusing existing ontologies. After reviewing the literature, several ontologies were considered to describe accounting entries [8]. Still, none of them represents bank statements oriented to PSD2 format and other related aspects such as invoice contextual information. These ontologies usually contain a class _Invoice_, _Receipt_ or other similar terms, but they do not ontologically describe an invoice, with relationships and components. In the proposed approach, the invoice concept plays an essential role since it allows considering all the meta-information, involving it to be further used in reconciliation mechanisms for linking with third-party bank statements. For example, those products or services the invoice refers to are usually unknown to the legal person or company that a given client has invoiced.
3. Enumerate important terms in the ontology. As mentioned in the previous step, important terms in OBO correspond to data in invoices and bank statements, involving open banking service transactions. Examples of these terms are: _companyld_, _customerld_, _issueDate_, _maturityDate_, _itemCurrencyAmt_, and _documentType_, which are related to invoicing, as well as those related to bank statements, such as: _Statement_, _Customer_, _Account number_, _Bank_, _Concept_, and _beneficiary_.
4. Define the classes and the class hierarchy. From the relevant terms, we extract which of them are classes of ontology. Figure 1 shows the set of classes that have been defined to describe an open bank service. Examples of these classes are: _Item_, _Statement_, _AccountObj_, and _Bank_. The class _Item_ comprises two subclasses, _Opened_ and _Cleared_, for specifying whether Items are pending to be paid or not.
5. Define the properties of classes. Object properties and data properties were created to connect instances of different classes and define their attributes. Examples of object properties are: _participating_, which connects a customer to the bank account; _statementHasOffice_, which relates a bank movement to the office in which it was registered; and _ItemHasCompany_, which connects an item with the company. Examples of data properties are: _statementConcept_, _beneficiary_, _accountNumber itemIssueDate_, _itemAmount_. Tables 2-6 describe details of these properties in description logic.
6. Define the facets of the slots. In this step, cardinality and value constraints are defined. In the proposed ontology, examples of constraints are: the range of the property _itemAmount_ has to be a decimal number; the range of the property _itemIssueDate_ has to be a date; the _concept_ of a statement has to be of type _string_, and so on.
7. Create instances. The instances (or individuals) in the current approach are generated from the JSON documents containing actual PSD2 bank statements and the CSV files with data of the items (invoices). These data are transformed to RDF through mapping functions according to the classes and properties defined in OBO, and an RDF knowledge graph is then created.