在银行主题模型中，每个数据仓库的实施公司会有金融行业或银行业的主题模型，这个模型会根据新的业务不断进行完善，是各实施公司的业务经验积累。一个良好的模型对数据仓库的实施起到了事半功倍的效果，虽然不同的公司会有不同的主题模型产品，但每个公司的产品基本上分为以下几个主题：
1、当事人（PARTY）
是指银行所服务的任意对象和感兴趣进行分析的各种对象。如：个人或公司客户、潜在客户、代理机构、雇员、合作伙伴等。一个当事人可以同时是这当中的许多角色。借助当事人主题的建立可以实现基于客户基本信息的分析，是实现以客户为中心的各种分析应用的重要基础。PARTY主题一般包括：
*外部机构、政府部门、行业监管机构等；
*在银行登记注册开立账户的单位、个人普通客户；
*和银行有业务往来的其他金融机构（如国内同业、海外代理行等）；
*银行机构的雇员（含柜员、客户经理等）；
*客户的干系人（如个人客户的配偶、子女，公司的法人等）；
*潜在客户（如交易对手，无账号交易客户等）；
那在实施过程中，除了对客户进行分类外，重点需要关注：
（1）客户ID：为每位客户确定一个唯一的ID，由于不同的系统都会有客户ID，如何分析是否是同一个客户？许多银行都会有ECIF系统来唯一确定客户，如果已经有全行的唯一客户ID，那将减少许多整合工作，只需按一定规则将其他潜在客户、干系人分配唯一ID即可。如果没有ECIF系统可以在主题模型进行整合，如按证件类型、证件号码、姓名、性别来识别唯一客户，将各源系统中的客户识别成唯一客户后，再将各源系统的客户信息进行整合。
（2）客户之间关系设计：由于一个客户可能有多个角色，一般可以通过客户关系表来确定。比如既是员工也是客户可在关系表中存放客户ID和员工ID的关系类型是同一个人，既是个人客户又是企业法人，可在关系表中存放客户ID和企业ID的关系类型为企业法人关系。
（3）客户主题是整个模型的中心，其它的所有主题都会和客户主题进行关联，因此如何与其他主题进行关联也需要重点考虑。
2、内部机构（Internal Organization）
内部机构是指可能是银行内部的组织机构（如分行、支行、网点、部门等），也可能是任何一个法人机构当事人的内部组织，严格意义上这些也是一种特殊的PARTY。概念比较宽泛，可能是正式机构，也可能是一些具有特定功能的团队。
内部机构在银行往往会有多套组织，每套组织机构都会有层级关系。如经营机构（支行与营业部以及管辖机构总分行），行政机构（部门科室包括各分支行中的部分科室），第三方组织（党组织支部、工会等）。因此需要梳理并做好分类。一般在分析中最常用的是经营机构组织。
通过该主题的建立要能够体现不同组织机构之间的层次隶属关系，同时还能够适应组织机构变动的灵活性以及交叉管理的需要。此外，该主题和当事人、渠道、地区、产品、账户、事件、营销活动等都有关联。如对产品而言，可能有多种角色，如创建、销售、监控等。
3、客户资产（ASSET）
该主题是所有可能采集到的客户的资产（负债）信息，也包括银行向外租赁的资产信息。这些信息的来源很多情况下是在客户申请贷款时所提供的各种担保品信息、抵质押品信息等。
该主题可以存放从业务系统能够取得到的所有的客户资产/负债，可以是客户的房地产、存货、机动车辆、在其他金融机构的存款、贷款，此外还包括住房公积金委托存款等。客户在本行的存款、贷款虽然也是他们的资产和负债，但存放在协议主题，不在资产主题体现了。随着目前互联网和外部数据的增加，该主题中的数据分类和字段也会不断扩展，所以除了房地产、汽车等实物资产，股票、期权等金融资产，还会有虚拟资产，比如游戏装备。
4、地域（LOCATION）
该主题是需要分析的任何区域，既包括传统类型的地址信息（如国家、地区、城市、区县、街道等），又包括如电话信息、邮箱、黄页等电子地址信息。LOCATION可以用于和银行的交互和沟通，也可以被用于某个特殊的用途（比如对帐单寄送地址等）。此外数据仓库出于分析的需要，可能还会需要一些类似“地区”等一些相对比较宏观的地域信息。另外随着移动互联网和物联网的发展，移动设备的设备码、接入IP、传感器、GPS定位数据也越来越多，所以该主题在实施中需要梳理全行的所有渠道并进行分类编码，由于该主题结构较简单，在实施中可以根据实际情况合并到客户主题中。
5、产品（PRODUCT）
产品主题是指为拓展市场占有率，满足客户更广泛需求而制定的可营销的交易品种的集合，产品是金融机构向用户销售的或提供给客户所使用的服务。产品必须是能够面向市场、面向客户的，并且必须要有回报发生的。产品可以通过产品特征加以描述，产品特征是金融机构提供的所有可以应用于产品的有效产品特征。它标识了金融机构在提供产品时的限制或附加条件。
目前银行的系统升级都在向产品方向改造，即通过配置产品特征方式来生成新的产品或产品包（捆绑销售的产品）。如果已经有全行级别的产品分类和编码的话可以直接复用，如果没有的话需要梳理，产品编码的数据需要业务主导，因为许多分析需要按产品维度进行分析，因此产品的分层和特征需要有全行共识，一般在数据治理的数据标准中，产品标准也是一个全行重要的标准。
6、协议（AGREEMENT）
协议主题是金融机构与当事人之间针对某种特定产品或服务而签立的契约关系，它可以是多样化的，如账户、客户和银行签订的合同等。当金融机构与客户之间针对某种产品或服务的条款和条件达成协议时，一个协议（AGREEMENT）就会被开立，因此协议是客户和银行往来的重要载体。也是银行主题模型中最重要和复杂的一个主题。
协议模型结构需要能够存储银行和客户签订的各种形式的协议，如各种存款账户、贷款账户、内部账户、贷款合同、担保合同、国际国内结算协议、客户理财合约等，也包括银行自营业务与交易对手之间的协议，如银行投资的债券交易、同业拆借协议等。银行的业务比较复杂，因此协议类型需要分类分层梳理设计，协议数量一般有成百上千，甚至更多。
协议是分析银行业务、产品的重要信息，每个协议的关键属性不同，但都需要保留历史变动记录以便后续分析。另外客户的申请也一般放在协议主题，比如信用卡申请信息、贷款申请信息等。
7、事件（EVENT）
事件是一个范围很广义的概念，它可以包含跟银行相关的任何动作的记录。它可以记录的范围非常广泛，可以记录各种与银行相关的活动的详细情况，包括交易数据，比如存款、提款、付款、收取信用卡年费、计算利息和费用、投诉、查询产品、查询地址、查询余额、网上交易等。一个事件可以是和客户/潜在客户或账户的任何接触和交易，数据仓库系统存储的事件应是一个原子级的事件，即最细粒度的交易信息。
事件可以分为金融事件、非金融事件、电子渠道事件等几类。金融事件又按业务分为存款帐户事件、卡银联交易事件、贷款帐户事件、国内结算事件、国际结算事件、中间业务事件和证券基金事件。电子渠道事件主要是来源于网银、手机银行、微信公众号、电话等渠道发起的交易。
事件主题的数据是整个主题模型中最多的数据，因此除了进行事件分类梳理、事件关系梳理外，事件表的设计和源系统表类似，只做编码的转换，甚至在物理实现中用视图来表示部分事件表，减少数据存储。另外事件表一般都有流水号，所以唯一标识事件的EVENT_ID只需要通过源系统简称+源系统流水号+交易日期 即可。
8、营销活动（CAMPAIGN）
营销活动主题用于记录针对客户所做的宣传、促销等活动的相关信息，是为了获取、维护、增强金融机构与客户的关系而开展的，其目的可能是为推广某些产品，也可能是为了树立市场形象。一个完整的营销行为应包括营销计划、营销活动以及实施信息。一个营销活动可以是金融机构为了获取、保留客户或者增强客户关系、占有市场的一种活动，可能是一种有明确市场目标的销售活动（如新产品推广等），也可能仅仅是跟客户的一种互动的交流活动（如客户调查等）。
由于银行营销活动灵活性较大，变化点多，模型不稳定，一般会新建CRM系统或营销系统来专门管理，因此在银行实施主题模型时该主题可能会舍弃。
9、渠道（CHANNEL）
该主题所描述的是当各种事件发生时，当事双方（主要是指客户和银行）进行交互和接触的手段及方法，通过它客户与银行进行接触、购买产品、使用服务并交流信息。
“渠道”从定义上看是一个当事人获取金融机构信息或者接受服务、购买产品的一种方法和机制，是一种“接触点”。一个“渠道”可能是一台机器（如某台ATM、POS、自助终端等），也可能是银行某个服务网点。通常定义ATM是一种“渠道种类”，某一台ATM机器是一个具体的“渠道”。从银行角度所关心的渠道种类包括：
1）电子渠道：如手机、网银、微信公众号、小程序、微博、官网等，另外随着银行与互联网合作越来越紧密，许多第三方互联网产品也是获取客户流量的渠道，如萨摩耶、支付宝、微信、今日头条等；
2）设备渠道：如ATM、POS、自助终端等；
3）人员服务：如网点、分理处、柜台等；
10、财务（FINANCE）
该主题主要包括银行的总账信息，是描述科目组织、控制、内部核算等银行核心科目账务以及预算管理有关的内容。该主题抽象地描述了银行内部账务的组织模式，能够适应不同的科目组织体系。财务主题一般变化较少。
该主题侧重于财务核算和管理，一般各行都有总账系统或模块来定义全行的科目体系，并对全行各账务系统的账务数据按进行科目汇总。所以财务主题也以行内的总账系统为主，同时纳入各源系统的账务汇总数据，便于与OF总账数据的对照以及总分核对检查。
总分核对是数据仓库中一种重要的数据校验方式，主要按账户所属科目进行账户余额汇总，将结果与总账或各账务系统中的科目余额进行汇总，以确保账户余额这类重要数据无误。