Założenie do wykorzystania mechanizmu Reporting Service do zasilanie danymi funkcjonalności RISK
Serwis pracuje na o wiele mniejszych wolumenach niż widoki zrobione na podstawie danych biznesowych obecnych już w tabelach. Tabele raportowe są ograniczone co do przechowywanych informacji w stosunku z tabelami biznesowymi
Serwis umiejscowiony jest na osobnej bazie niż ta, na której znajdują się dane biznesowe. Z tego powodu działanie jednego nie ma negatywnego wpływu na działanie drugiego. Działanie APIHUBa nie zostaje przez serwis obciążone.
Z powodu zaprojektowanych rozwiązań, reporting serwis pozwala na szybszy dostęp do raportów (niż miało to miejsce w momencie tworzenia widoków na bazie z danymi biznesowymi), jest on również pozbawiony ryzyka pojawiania się 'timoutów', jak miało to miejsce przy widokach na tabelach biznesowych.
Dane z tych raportów można też z czasem archiwizować, gdyż nie są potrzebne z biznesowego punktu widzenia.
Wykorzystany mechanizm
Do zasilania opisanych powyżej tabel wykorzystany został mechanizm Reporting Service. Jest to standardowy mechanizm udostępniania danych przez APIHub dla systemów zewnętrznych w modelu DB-DB.
Opis mechanizmu standardowego znajduje się w Standardowej Dokumentacji APIHub :Reporting Service
Tabele dla RISK udostępniane przez mechanizm Reporting Service
Dane dla funkcjonalności RISK są wystawiane w 3 tabelach w schemacie reporting.
Tabela Account
Filtracja rekordów:
Kolumna | Źródło | Przekształcenie/ słownik | Dodatkowe info |
[account_psd2hub_id] | - | Techniczny identyfikator rachunku nadawany przez APIHub | |
[user_psd2hub_guid] | - | Techniczny identyfikator Klienta (user) nadawany przez APIHub. Ten identyfikator jest łączony z usercompany (User-Company-BankAccount ) jako że dla każdego Klienta retail mamy logicznie 1 rekord w tabeli company (1 do 1) na który wskazuje bankaccount.companyid. | |
[account_psd2hub_bankName] | Bank.OfficialName | Zgodnie z parametryzacją biznesową APIHub | |
[account_psd2hub_iban] | BankAccountIdentifier.Value dla BankAccountIdentifierScheme.Name = ‘IBAN’ | IBAN (pobierana z tabeli BankAccountIdentifier.Value dla BankAccountIdentifierScheme.Name = ‘IBAN’) | |
[account_psd2hub_name] | BankAccount.AccountName | ||
[account_psd2hub_balance_amount] | BankAccountBalance.Amount dla BankAccountBalance.BalanceType = 2 | Słownik typów sald (BalanceType): Balance types | |
[account_psd2hub_currency] | BankAccount.Currency | join z tabelą Currency po id (Code) | Wartość w standardzie ISO 4217 |
[account_psd2hub_createDate] | BankAccount.CreateDate | tabela BankAccount | Data stworzenia rachunku w bazie. W przypadku usunięcia consentu rachunek pozostaje jako nieaktywny, jeśli więc zajdzie sytuacja usuniecia zgody (bez usunięcia rachunków), a nastepnie dodana zgoda na to samo konto, data się nie zmieni (będzie to data tego pierwszego insertu). Natomiast bankowość elektroniczna SNT, biznesowo usuwa zawsze zgodę i rachunki, więc praktycznie będzie to data dodania rachunki dla nowej zgody. |
[account_psd2hub_syncFromDate] | BankAccount.syncFromDate | tabela BankAccount | Data od której agregowane były transakcje. Jest to zakres historyczny (data od) dla którego nastąpiła pierwsza sesja AIS (w dacie BankAccount.CreateDate). Data od której APIHUB pobrał transakcje od ASPSP. To niekoniecznie musi być BankAccount.CreateDate- 1460 dni, w przypadku zaciągania 90 dni data będzie inna. Jest to ilość dni wstecz transakcji o którą poprosiliśmy ASPSP, przy pierwszej agregacji klienta. Nie zmieni się ona dopóki rachunek nie zostanie usunięty z bazy. Można więc uznać, że jest to potencjalna najstarsza data transakcji na tym rachunku klienta (może być dużo krótsza o ile klient nie ma tak długiej historii). Nowe refreshe więc nie nadpiszą tej daty, tak samo nowe SCA itp. |
[account_psd2hub_syncLastDate] | BankAccount.syncLastDate | - | Data ostatniej sesji AIS dla rachunku (wchodzi w to także odświeżenie przez batch, wywołanie metody RAA= true, wywolanie metody sync) |
[account_psd2hub_syncStatus] | BankAccountSync.Status | Jeśli BankAccountSync.Status = 1 AND BankAccountSync.TransactionStatus = 4 to account_psd2hub_syncStatus = 0, w przeciwnym wypadku 1 | Enum dla BankAccountSync.Status
Active oznacza iż wszystko zostało zakończone sukcesem Idle - aktualnie nie wykorzystujemy Failed - błąd podczas agregacji na etapie kont InProgress - agregacja kont trwa Initial - aktualnie nie wykorzystujemy Enum dla BankAccountSync.TransactionStatus:
NotStarted - chwilowy etap przed rozpoczęciem agregacji transakcji PartiallyCompleted - aktualnie nie wykorzystywany Completed - wszystkie transakcje przeprocesowane prawidłowo Failed - błąd procesowania transakcji dla danego konta |
[account_psd2hub_LastMonthEodBalance] | BankAccountBalance.Amount | Saldo księgowe klienta na koniec poprzedniego miesiąca, w przypadku braku informacji będzie to pierwsze dostępne saldo Wyliczane w zależności od posiadanych danych na BankAccountBalance.Amount lub Transaction.BalanceAfterTransaction przy czym konieczne było spełnienie odpowiednich warunków – dla BankAccountBalance.BalanceType = 2, a dla Transaction.TransactionStatus = 5 oraz Transaction.AccountingDate z poprzedniego miesiąca | |
[account_psd2hub_LastMonthEodBalanceDate] | BankAccountBalance.Date | Wyliczane w zależności od posiadanych danych na BankAccountBalance.Date oraz na Transaction.AccountingDate przy czym konieczne było spełnienie odpowiednich warunków – dla BankAccountBalance.BalanceType = 2, a dla Transaction.TransactionStatus = 5 oraz Transaction.AccountingDate z poprzedniego miesiąca |
Tabela Transaction
Filtracja rekordów: wszystkie transakcje dla kont w tabeli Account
Kolumna | Źródło | Przekształcenie/ słownik | Dodatkowe info |
[trx_psd2hub_trxId] | Techniczny identyfikator transakcji nadawany przez APIHub | ||
[account_psd2hub_accountId] | Transaction.AccountId | Połączenie rachunek - transakcja | |
[trx_psd2hub_accountingDate] | Transaction.AccountingDate | ||
[trx_psd2hub_effectiveDate] | Transaction.EffectiveDate | ||
[trx_psd2hub_amount] | Transaction.OperationAmount | ||
[trx_psd2hub_amount_abs] | Transaction.OperationAmount | Wartość bezwzględna | |
[trx_psd2hub_c_d] | Transaction.CreditOrDebit | Credit = 1, Debit = 0 | Kierunek trx jest wyliczany w APIHub na podstawie znaku i/lub salda przed i po trx. Wartość Credit or Debit jest dla nas bardziej rzetelna. |
[trx_psd2hub_currencyCode] | Transaction.CurrencyId | join z tabelą Currency po ID (Code) | Wartość w standardzie ISO 4217 |
[trx_psd2hub_status] | Transaction.Status | Unauthorised = 1, | |
[trx_psd2hub_senderIban] | Transaction.SenderAccount | ||
[trx_psd2hub_sender] | Transaction.Sender | ||
[trx_psd2hub_recipientIban] | Transaction.RecipientAccount | ||
[trx_psd2hub_recipient] | Transaction.Recipient | ||
[trx_psd2hub_title] | Transaction.Title |
Tabela User
Filtracja rekordów: Dokładny opis działania (logika biznesowa) w CR:
Kolumna | Źródło | Przekształcenie/ słownik | Dodatkowe info |
[user_psd2hub_guid] | Techniczny identyfikator Klienta (user) nadawany przez APIHub. Ten identyfikator jest łączony z usercompany (User-Company-BankAccount ) jako że dla każdego Klienta retail mamy logicznie 1 rekord w tabeli company (1 do 1) na który wskazuje bankaccount.companyid | ||
[user_psd2hub_ext_identifier] | AspNetUsers.Externald | Identyfikator Klienta przekazany do APIHub przy jego tworzeniu | |
[psd2hub_registrationDate] | AspNetUsers.RegistrationDate | Data założenie rekordu usera w APIHub | |
[user_psd2hub_nik] | UserIdentifier.Value where Schemeid = 3 | join z tabelą UserIdentifierScheme | Dodatkowy identyfikator przekazywany do APIHub |
[user_psd2hub_cif] | UserIdentifier.Value where Schemeid = 4 | join z tabelą UserIdentifierScheme | Dodatkowy identyfikator przekazywany do APIHub |
[user_psd2hub_syncStatus] | jeśli status (wyspecyfikowany w tablicy risk_ETL_accounts_view w polu account_psd2hub_syncStatus) jakiegokolwiek rachunku klienta ma wartość odpowiadającą znaczeniu: "zakończony bez błędów" to pole powinno przyjąć wartość 0 w przeciwnym przypadku 1 | ||
[user_psd2hub_changeLastDate] | data ostatniej agregacji LUB od-agregowania rachunku klienta (data ostatniej zmiany w ramach udzielonych/odwołanych przez klienta zgód) | Dokładny opis działania (logika biznesowa) w CR: |
Dodatkowe wymagania/ modyfikacja
1. Po usunięciu wszystkich agregacji dla danego klienta. Tabela [reporting].[User] zwraca dane Klienta podczas gdy widok [dbo].[risk_ETL_users_view] tego nie robi.
Doprecyzowując: pojęcie usunięcie agregacji jest niezgodne z działaniem APIHub. Agregacja jest procesem którego wynikiem może (ale nie musi) być:
utworzenie rekordu zgody Klienta który jest odzwierciedleniem zgody na styku PSU-TPP. Zgoda ta wymaga autoryzacji w procesie SCA po stronie ASPSP
zapisanie w bazie LDS danych o agregowanych rachunkach i transakcjach na tych rachunkach (rachunki objęte zgodą)
przeniesienie tych danych do struktur raportowych (z których korzysta Reporting Service) w trybie asynchronicznym.
Klient (user) reprezentujący byt jakim jest PSU tworzony jest przed pierwszą agregacją w APIHub (zanim się ona rozpocznie) i nie jest usuwany w wyniku:
usunięcie zgody
usunięcia danych o rachunku(ach) z APIHub, bez względu na to czy po danej operacji usunięcie pozostaje 0 lub więcej rachunków w APIHub.
Rekord Klienta (PSU) jest zachowywany na potrzeby audytowe i dla zachowania ciągłości historii zgód (również tych usuniętych i wygasłych).
Dlatego też usunięcie danych o rachunkach (również wszystkich) nie powoduje usunięcia rekordu Klienta z widoku który jest zwracany przez Reporting Service.
Jeżeli wymagane jest zwracanie rekordów dla Klientów posiadających co najmniej jeden aktywny rachunek (rachunek nie został explicite usunięty) to jest to możliwe do zaadresowania poprzez stworzenie nowej tabeli w której będą zwracani tylko Klienci spełniający to kryterium.
rachunkiem spełniającym warunki filtracji, to w tablicy users nie powinno być dla niego krotki. Ze względu na wskazaną przez Pana Krzysztofa potrzebę zwiększenia przejrzystości rozwiązania, adekwatności nazwy oraz reprezentacji stanu faktycznego, utworzona zostanie DODATKOWO tablica o proponowanej nazwie USERS_ALL prezentująca wszystkich userów, niezależnie od aktualnego statusu ich agregacji.
2. Pole [reporting].[User].[user_psd2hub_changeLastDate] odświeża się po każdym RAA=true – powinno po nowej agregacji lub deagregacji konta.
W APIHub możliwe są następujące zdarzenia w kontekście danego Klienta:
pierwsza agregacja danych o rachunkach i transakcjach z ASPSP poprzedzona wydaniem nowej zgody i jej autoryzacją w procesie SCA -> modyfikuje changeLastDate
Odświeżenie danych o rachunkach i transakcjach z ASPSP na podstawie aktywnej zgody (poprzez odświeżenie na-żądanie i w trybie batch) -> brak wpływu na changeLastDate
inwalidacja zgody po stronie APIHub na podstawie informacji przekazanej przez ASPSP. Status zgody zmienia się na nieaktywny. Dana (nieaktywna zgoda nie jest dalej uwzględniana w procesie odświeżania (2). -> brak wpływu na changeLastDate - deaktywacja zgody nie spowodowała usunięcia danych z LDS, więc z naszego punktu widzenia klient nadal ma zgodę na prezentację danych za zadany okres, z zastrzeżeniem braku możliwości pobierania nowych transakcji.
usunięcie zgody poprzez wywołanie dedykowanej metody APIHub -> modyfikuje changeLastDate
usunięcie danych o rachunku poprzez wywołanie dedykowanej metody APIHub > nie rozumiem w jaki sposób można wywołać taką metodę - Edycja zgody np. w celu zmiany zakresu zgody de facto powoduje odwołanie poprzedniej zgody i wyrażenie nowej zgody o innym zakresie=> zatem zakres wpływu na pole changeLastDate zgodny z punktami powyżej.
przedłużenie zgody potwierdzone ponownym SCA po stronie ASPSP -> rozumiem że mowa o odświeżeniu zgody, którego klient może dokonać w każdym momencie, nie tylko w momencie gdy aktualna zgoda wygasła.
z modyfikacją zakresu zgody (jeżeli ASPSP dopuszcza taką możliwość) => > Odświeżenie zgody z zaznaczeniem innego zakresu rachunków objętych zgodą (niektóre banki to umożliwiają) -> powoduje, że rachunek który wyłączono z zakresu nadal jest dostępny w LDS z historią dotychczas pobraną, a więc nie usuwamy rachunku (choć może powinno się to dziać), co z kolei przekłada się na brak zmian na polu changeLastDate. Rachunek nowo dodany, rozszerzający zakres zgody, pojawia się w LDS co za tym idzie jeśli nastąpiło rozszerzenie to powinniśmy mieć aktualizację na polu changeLastDate. jeśli ograniczono zakres, ale nie usunięto rachunku z LDS to ten element nie wpływa na pole changeLastDate, jeśli zaś, po usunięciu rachunku z zakresu zgody nastąpi również jego usunięcie z LDS to powinna nastąpić zmiana na polu changeLastDate
bez modyfikacji zakresu zgody => Brak wpływu na changeLastDate