# Regulamento Geral sobre a Proteção de Dados(RGPD) in Santander's Insurance systems
The present paper describes the technical solution of a <ins>transversal component</ins>, which is composed of libraries, microservices, web applications, cache, database, etc.
This <ins>transversal component</ins> was designed in the context of **Santander** bank's internal area, called **Insurance**, wich have many kinds of insurances, e.g.: "Proteção Seguro Lar", "Proteção Seguro Auto", "Proteção Seguro Responsabilidade Civil", "Proteção Seguro Leasing Mobiliário" and "Seguro Proteção Empresa Acidentes de Trabalho".
## Goal
The existence of identical functionalities, which were implemented in duplicate, in the Insurance area systems. Also the lack of reusable components that can be implemented in new projects, as well as the scenario in which there is a change in rules and characteristics of some common functionality that causes changes in several systems, motivated this technical proposal to solve such problems. With this solution, the aim is to reduce application maintenance costs, reduce time to deliver features, standardize use, flexibly maintain content, etc.
## Strategies
Develop reusable components that can be used simply and in any technical solution.
Create components for web applications, as they are widely used.
Standardize APIs that provide functionality to those web applications.
Management mechanisms of information, where an operator can change texts (which will be shown on the user interfaces).
## Architectural pattern
The **microservices pattern** inherently has the characteristics of having loosely coupled components, scalability, reusability, rapid development, etc.
Therefore, this is the most appropriate standard, according to our objective, which leads to this solution.
### Principles
- Usability: Ability of be simple to use. This applies when a developer takes a library to use in its source code.
- Maintainability: Ability of the system to make changes with certain ease.
- Reusability: Ability for components to be used in other software systems.
- Interoperability: Ability of different systems to operate successfully by communicating and exchanging information.
- Reliability: Ability to remain operational over time.
- Scalability: Ability to handle increased or decreased load without affecting performance.
- Abstractability: Ability of the system in hiding API´s implementation details allowing much more simplicity and enhancing the other principles above (such as reusability and usability).
## Design
||
|:--:|
| *Figure 1: Generic Soluction* |
### Features
- <ins>Decoupling</ins> the RGPD features and functionalities from other insurances to turn it in a "transversal component";
- <ins>Componentization</ins> of the RGPD features and functionalities and divided them into various components;
- <ins>Decentralized governance</ins> of RGPDs information, enables standardizing and management of RGPD text more facilitated to a backoffice-operator;
## Components
The following componets are part of the transversal macro componet.
### I. Web Library
1. **Goal:** Provide a single library to be used to all insurances.
2. **Characteristics:**
- Global Reusability;
- Features and Functionalities encapsulated;
- Single point of maintenance
3. **Functionalities:**
3.1. Section to display **texts**;
3.2. Button to provide user functionality to **accept** terms;
3.3. Button to provide user functionality to **reject** terms;
4. **Development:**
The developer - with knowledge about the funcionalities to implement, creates the library using the standard framework from Santander. The source code will rest on git repository.
5. **Deliver:**
This library will be on Santander's artifact and binary management system. In order to be used to all developers that wants incorporate this library on they frontend page.
6. **Using Library**
The developer has the flexibility to define the better way to display the RGPD information to his users, could be,for example: In a dialog, a page, etc.
### II. RGPD Microservice
1. **Goal:** Execute specific business functionalities mantaining the data and comunicating with other microservices.
2. **Characteristics:**
- development and independent scalabity;
- easy maintenance and updating;
- More flexibility;
- Abstraction;
3. **Functionalities:**
3.1 Create RGPD terms;
3.2 Accept RGPD terms;
3.3 Update RGPD terms (Aquando a criação ou instauração de um novo RGPD; será feito um update e nova atualização de todos os existentes?)
4. **Development**:
5. **Deliver**:
- Code Deployment: Client Cloud platform;
- Distribution: website;
- Release Management: Git??;
- User Communication: ?? ;
- Feedback Collection: website;
### III. RGPD User Interface (backoffice)
1. **Goal:** Empower back-office with the tools they need to manage and maintain the application effectively
2. **Characteristics:**
- User Friendly interaction;
- Usability;
- Monitoring and Reporting;
- Secure;
- Cross-Browser Compatible;
3. **Functionalities**:
3.1 Section to display and write texts - graphical interface (best way) or (via postman).
3.2 Button to provide user functionality to update and confirm changes in RGPD terms text. *(Os RGPDs variam consoante os seguros?)*
4. **Development**: _como e quem irá desenvolver este componente?_
5. **Deliver**:
- Code Deployment: ;
- Distribution: ;
- Release Management:
- User Communication: ;
- Feedback Collection: ;
### IV. Database
1. **User** - username(PK) , pass, type (colab, client,...)
2. **Client** - nif(PK), username(FK), email, ...
3. **Textos RGPD** - id_rgpd (PK) , text.
4. **Seguro** - id_insurance(PK), insurance_name, inusrance_cenas ...
5. **user_RGPD_Seguro** - username(FK), id_rgpd(FK), id_insurance(FK)
7. ...

# Questions:
- Se o texto RGPD for alterado, é necessario que todos os clientes que já consentiram, devam consentir com o novo texto RGPD?
- Miqueias: Eu acho que não, porque o seguro já foi adquirido. Mas se o processo está on-going (não finalizado), creio que ele deva aceitar novamente.