A Customer-Centric

Banking Platform Powered

by MongoDBAlan Reyes Vilchis

Technical Lead, Customer 360

Customer 360 Development Area

Customer 360 was born with MongoDB

adoption at Banco Azteca

Our objective is to build a customer-centric

services platform to be used by all of the

companies of the group

Grupo Elektra

Banco Azteca

Banco Azteca is changing its way to relate with the

Customers, under the motto:

“Everything that you can do in a branch,

you can do it in our app”

To achieve this objective we needed to review our

workflows

Before Platform 360

Branch

Unique

Customer

Banking Core Loans

App

Backend

After Platform 360

Platform 360

BranchApp

Backend

Unique

Customer

Banking

CoreLoans

Services

What are we building?

Digital Mobile Bank

iOS

Application

Android

Application

Application

Backend

Customer 360

Single View

System of

Record

Customer 360

Single View

Money Exchange before the Single View

Money Exchange

at branch

Banking

Core

Unique

Customer

Money Exchange

own database

The identification of customer required searches to different systems, using

different contracts and capabilities for each one of them

Money Exchange after the Single View

Money Exchange

at branch

Customer 360

Single View

The identification of customers can be done now in a single search, retrieving

results with the same or better quality

Single View Design

Person

Master

Sources

UC_1-1-1-1

ALNOVA_12345678

UC_1-3-20-12

LOANS_1-1-1-1

Structure of a Person’s Record on the single view:

Single View

Single View Data Flow

Banking Core

MS SQL Server

Unique Customer

Oracle

Loans

AS400

REST API

Unified Database

Talend

Talend

Scop

e

Bu

sin

ess

Ben

efi

ts

Transactions are written first to the single view, which

propagates the data back to the source system of record.

Writes are performed concurrently to the source systems as

well as the single view

The single view data model is enriched with additional

sources to serve more applications, including real-time

analytics. The single view becomes a platform serving

multiple applications

Single View

Platform

Records are copied via ETL or message queue

mechanisms from the source systems into the single view,

serving read queries. The single view serves one specific

application

Single View

Application

Single View

First

Dual Writes

Read

Centric

Transforming the role of

the single view

Reads & Writes

Single View Maturity Model

https://www.mongodb.com/blog/post/10-step-methodology-to-creating-a-single-view-of-

your-business-part-3

Architecture for Writes to the Single View

ET

L o

r M

es

sa

ge

Qu

eu

e

Web

Mobile

CRM

Mainframe

Single View Call Center

Analytics

Technical

Support

Billing

Update

Queue

Reads

Writes

Source Systems Consuming Systems

Load

https://www.mongodb.com/blog/post/10-step-methodology-to-creating-a-single-view-of-

your-business-part-3

System of Record

• New business logic and constraints for our new

mobile-first use cases

• Unique Customer didn’t allow to register

anonymous customers

• Need to manage the customers of new

businesses without requiring them to have their

own databases

Why was it needed?

Design of the System of Record

Structure of a Customer Record

Customer

Personal Data

Business

Extended A

Business

Extended B

Business

Extended C

(Virtual)

System of Record Data Flow

Unique Customer

Oracle

System of Record

REST API

Database Banking Core

MS SQL Server

Main technologies

• Horizontal scaling

• It’s flexible schema allows us to

– Reduce the development time in half, by integrating

the development work on the database and the

application

– Keep related objects with variable schemas together in

the same collection or array

MongoDB

Java

• Enterprise trusted

• Strong typing

• Plenty of libraries

Technical challenges

Integration of customer data

ID: 1

Name: John Smith

ID: 2

Username: jsmith

ID: 1

Name: John Smith

Username: jsmith

ID: 2

Primary: 1

Solution on a Relational Database

CustomerPrima

rycustomer_id

primary_id

CustomerData

customer_id

name

username

CustomerId

customer_id

Solution on MongoDB

{

"id": 1,

"name": "John Smith"

}

{

"id": 1,

"name": "John",

"username": "jsmith"

}

{

"id": 2,

"principal": 1

}

{

"id": 2,

"username": "jsmith"

}

Keep related objects together

Unique Customer ID

channel: 1

branch: 13

id: 87

Alnova ID

id_alnova: 1

Unique Customer ID

channel: 2

branch: 23

id: 54

Customer

Solution

CustomerLinkedUniqueCustom

ercustomer_id

channel

branch

id

CustomerLinkedAlnova

customer_id

alnova_id

Customer

customer_id

{

"id": 1,

"linked_ids": [

{

"origin": "bank",

"id": {

"bank_id": 1

}

},

{

"origin": "branch",

"id": {

"channel": 1,

"branch": 13,

"id": 87

}

},

{

"origin": "branch",

"id": {

"channel": 2,

"branch": 23,

"id": 54

}

}

]

}

VS

Integration of Java and MongoDB

Technologies stack

MongoDB

Native Java

Driver

MongoJack

Jackson

Value.Immutabl

e

Output:

Value.Immutables

Creates immutable implementations based on a contract

Output:

Value.Immutables

Immutables enforces consistency

Jackson

@Value.Immutable

interface Customer {

@JsonProperty("_id")

int getId();

@JsonProperty("first_name")

String getFirstName();

@JsonProperty("last_name")

String getLastName();

}

{

"_id": 1,

"name": "JOHN",

"first_name": "SMITH",

"last_name": "SMITH"

}

Jackson Mixin support

// Data Class

class Data {

String property;

String getProperty() {

return this.property;

}

String setProperty() {

tis.property = value;

}

}

Jackson

ObjectMapper

Data

instance

JSON// Annotated Contract

interface DataMixin {

@JsonProperty("property")

String getProperty();

}

MongoJack

Customer

MongoDB

Collection

JacksonCollection (MongoJack)

ObjectMapper (Jackson)

MongoJack Module

MongoDB Java Driver

DBObject

Common Library

Customer Class

Reusability

Customer

instance

JacksonCollection (MongoJack)

ObjectMapper (Jackson)

MongoJack

Module

JSON

HTTP API (Jersey Server)

ObjectMapper (Jackson)

MongoDB

Collection

HTTP Client (Jersey Client)

ObjectMapper (Jackson) Customer

object

Distributed transactions

Current Model

Customer

Extended A

Customer

Extended B

Customer

Customer Model

addAddress()

setName()

addLinkedId()

beginModify()

commit()

Controller

Proposed Model

Transaction

Actions

apply()

SetNameAction

AddLinkedIdActio

n

AddAddressAction

Customer

Extended A

Customer

Extended B

Customer

Controller

Action

prevalidate()

apply()

notify()

Transaction flow

Transaction

Prevalidation

Application

Notification External

services

Database

Summing up

Summary

To sum up, I showed you:

• How we have build our single view

• How we have build our system of record

• How we used MongoJack, Jackson and

Value.Immutables to map Java objects to MongoDB and

back

• How we designed a framework to apply complex

transactions

Thank you!

On behalf of the

Customer 360 Development Team

Q & A

Alan Reyes VilchisTechnical Lead, Customer 360

@KuttKatrea

Font Awesome by Dave Gandy - http://fontawesome.io