Banking Data Model

Data Vault 2.0
1

Hello Group, Thank you for some great discussion.
I am trying to build a DV2.0 based on a bank domain.
Business Entities :slight_smile:

  1. Customer
  2. Account : Account is further broken into following sub-types
    a. Savings
    a. Checking
    a. Loans

The source has as of date values for each of the account sub-types and prepares a full load everyday.

Based on DV2.0 principles, I have been able to create the following DV objects:

  1. Hub_Customer . BK : CUSTOMER_KEY
    a. Sat_customer_pii : To isolate PII attributes
    a. Sat_customer_attribute : For non-pii attributes
  2. Hub_Account : BK : ACCOUNT_NUMBER
    a. Sat_account_attributes (these are not account sub_types)
  3. Link_Customer_Account

Question

  • I am unable to model the account sub-types. Should these be satellities on the Link_Customer_Account ?
  • The account sub-types have Primary & Seconday Customers that are similar to Primary & Seconday account holders. How should these be modelled ?
ACCOUNT_NUMBER JOINT_ACCOUNT CUSTOMER_KEY_OF_ACCOUNT_OWNER CUSTOMER_KEY_OF_JOINT_ACCOUNT_OWNER_1 CURRENT_BALANCE DATE_UPDATED_LAST
508787686 Y VIS1460787878 VIS14600545454 2,598.16 2023-03-24 00:00:00.000
508787121 Y VIS1460566565 VIS14600222112 3,498.16 2023-03-24 00:00:00.000

Will appreciate your thoughts on this ?

2

Hello team, Any recommendations on the following :slight_smile:

  • How should the account sub-types be modeled ?

  • The account sub-types have Primary & Seconday Customers that are similar to Primary & Seconday account holders. How should these be modelled ?

3

@patrickcuba or other Data Vault greats. Looking for some guidance on this. Thank you in advance

4

I’m in a (credit risk) banking domain currently too. I’m following our LDM where current (/checking) accounts have been separated from financing products (loans) and deposit products. All have an account number as a BK, but because the business concepts are so different, I created three separate hubs.

For the primary and secondary customers, I would create two links

  • Link_Account_Customer_Primary
  • Link_Account_Customer_Secondary

Both will reference the same Hubs. And you can create two Effectivity Satellites, one for each link.

For the account holders, you can take the same approach.

1 Like
5

Greats? :smiley:

The link looks fine, some thoughts

Is the hub table at the right grain? How do you tell the account type? Should you have one account hub or several account hubs?
Separate grain: does the source supply these as seperate landed content or combined?
Separate — win-win, combined — can they split it? No, then you should split them in pre-staging

Same grain (if you have decided to do so): would it make sense to deploy views by account type? hub_savings_account, hub_checking_account, hub_loan_account. They are essentially different things, but, up to you of course!

How do you identify the primary/secondary account owner? Is it key_1 and key_2 as you have depicted? If so then your link will contain:

  • dv_hashkey_(ACCOUNT_NUMBER) — hub_account (or hub_loan_account… etc.)
  • dv_hashkey_(CUSTOMER_KEY_OF_ACCOUNT_OWNER) — hub_customer
  • dv_hashkey_(CUSTOMER_KEY_OF_ACCOUNT_OWNER_1) — hub_customer
    If the source supplies it this way then this link maintains the Unit of Work

More specifically to your questions:

  • Should these be satellites on the Link_Customer_Account? — depends, are the details describing the relationship or the account? If the account then hang them off the hub_account
  • How should these be modelled? With as fewest tables as possible!