Learn why a tier 1 bank, top 5 insurance provider and other global financial services companies are flocking to MongoDB. This webinar focuses on how firms use MongoDB to generate a single customer view not only to comply with KYC and other regulations, but also to engage customers efficiently, which helps reduce churn and increase wallet share while still reducing costs. We will focus on how MongoDB's dynamic schema, real-time replication and auto-scaling make it possible to create a global, unified data hub aggregating disparate data sources, which can be made available to customers, customer service representatives (CSRs), and relationship managers (RMs).

1. How Financial Firms Create a Single
Customer View with MongoDB
Matt Kalan, FS Solutions Architect
Email: Matt.kalan@10gen.com
Twitter: @matthewkalan

2. 2
• MongoDB Introduction
• Common FS Use Cases
• Case Study
• Pre-requisite Data Analysis
• Loading Cross-Silo Data
• Querying Single Customer View
• Unique Capabilities of MongoDB
• Summary of Value
• Q&A
Agenda

3. 3
Introduction
10gen is the company behind MongoDB –
the leading next generation database
Document-
Oriented
Open-
Source
General
Purpose

4. 4
10gen Overview
200+ employees 600+ customers
Over $81 million in funding
Offices in New York, Palo Alto, Washington
DC, London, Dublin, Barcelona and Sydney

5. 5
Database Landscape
• No Automatic Joins
• Document Transactions
• Fast, Scalable Read/Writes

6. 6
Why MongoDB is fast and scalable
Better data locality
Relational MongoDB
In-Memory
Caching
Auto-Sharding
Read/write scaling

7. 7
MongoDB Business Benefits
Increased Developer Productivity Better Customer Experience
Faster Time to Market Lower TCO

8. 8
MongoDB Technical Benefits
Horizontally Scalable
-Sharding
Agile &
Flexible
High
Performance
-Indexes
-RAM
Application
Highly
Available
-Replica Sets
{ name: ―John Smith‖,
date: new Date(),
address: ―10 3rd St.‖}

9. 9
Common FS Use Cases
Capital Markets
1. Reference Data
Management
2. Risk Analysis &
Reporting
3. Tick Data Capture
& Analysis
4. Customer Portal
5. Portfolio and P&L
Reporting
6. Trade Repository
7. Order Capture
Banking
1. Single View of
Customer
2. Online Banking
3. Reference Data
Management
4. Risk Analysis &
Reporting
5. Product Catalog
6. Cybersecurity
Threat Analysis
Insurance
1. Single View of
the Customer
2. Online Quoting
3. Customer Portal
4. Risk Analysis &
Reporting
5. Reference Data
Distribution
6. Policy Definition
Catalog

10. 10
Single View of a Customer -
Requirements
• Extract customer info from many source systems
as often as desired
• Load into one database and application
• Link data together for each customer
• Query for all customer and associated product
info at once
• Enable CSRs, RMs/Agents, customers, etc. to
know all customer and product information at
once

11. 11
Single View of a Customer –
Why MongoDB?
• Dynamic schema => can handle vastly different data together and
can keep improving and fixing issues over time easily
• High scale/performance => directly impacts customer experience or
CSR MTTR so every second counts
• Auto-sharding => can automatically add processing power as
customers and products are added
• Rich querying => supporting ends users directly requires multiple
ways of access and key/value is not sufficient
• Aggregation framework => database-supported roll-ups for analysis
on data hub for customer information by marketing, sales, etc.
• Map-reduce capability (Native MR or Hadoop Connector) => batch
analysis looking for patterns and opportunities in data hub

12. 12
• MetLife Leapfrogs Insurance Industry with
MongoDB-Powered Big Data Application
• New York—May 7, 2013—10gen, the MongoDB company, today
announced that MetLife, Inc. selected MongoDB as the data engine
for ―The Wall‖, an innovative customer service application that went
live last month. …
• http://www.10gen.com/press/metlife-leapfrogs-insurance-industry-mongodb-
powered-big-data-application
And We’ve Done it Before

13. 13
High Level Data Flow
Source
database 1
Source
database 2
…
Source
database N
ETL or
Custom app
Document
• per product
• per customer
CSR Application
Customer
Application
Agent/RM
Application
OLTP/real-time
access
Queue to Update
Source Systems

14. 14
Single global view of customers’ product
portfolio and interactions
Case Study: Tier 1 Global Insurance
Provider
Problem Why MongoDB Results
• Siloed view of customer
across products
• Changing policy
definitions takes months
or more
• Source systems are
critical but stuck on old
technology
• Leverage dynamic
schema to include
evolving policy details
• One data hub across all
contact channels for
consistent customer view
• Leverage replication for
high availability to reduce
pressure on ops team
• Leverage sharding to
scale linearly
• Able to deliver in 3
months with $2M, when
previous attempts costing
$25M failed with no results
• Unified customer view for
call center and web site
with changes available to
all channels
• Dramatically lower cost
through less and shorter
calls

15. 15
Case Study: Tier 1 Global Insurance
Provider
Source
database 1
Source
database 2
…
Source
Database 40
Custom app
exports JSON
Document
• per product
• per customer
CSR Application
Customer
Application
Agent/RM
Application
OLTP/real-time
access
Future phases

16. Pre-requisite Data Analysis

17. 17
• What is the scope of customer info to aggregate?
– Start with a manageable amount
– Focus on satisfying particular valuable purposes (e.g minimizing
MTTR and re-routed calls)
– Need executive political support to get time from all groups
• How to link data across customers and products?
– Identify the rules both exact and fuzzy
– Specify common fields
– Try to normalize but dynamic schema is tolerant
– Can always refine rules as you go even based on human
feedback
What questions to answer to feed
into design?

18. Load Data into MongoDB

19. 19
Customer Records in Source
Systems, e.g. banking
Personal Bank Accounts
• Account ID
• Open date
• First name
• Last name
• Joint First Name
• Joint Last Name
• Joint SSN
• Address
• City
• State
• Zip
• Address 2
• Home phone
• Work phone
• APR
• Account type
• Branch ID
• Region ID
• ….
Credit Cards
• CC number
• SSN 1
• Full name 1
• Address 1
• City 1
• State 1
• Zip 1
• SSN 2
• Full Name 2
• Address 2
• City 2
• State 2
• Zip 2
• Primary phone 1
• Mobile phone 2
• Issue date
• Reward type
• ….
Mortgages
• Mortgage ID
• Borrower name
• Borrower SSN
• Borrower address
• Borrower city
• Borrower state
• Borrower zip
• Co-borrower SSN
• Co-borrower name
• Co-borrower address
• Co-borrower city
• Co-borrower state
• Co-borrower Zzp
• Mobile phone
• Effective date
• Term
• Interest
• Money down
• Principal loan
• Total loan
• ….

20. 20
{
_id : ObjectId("4e2e3f92268cdda473b628f6"),
accountID: 9874983789,
accountType: “Checking”,
firstName : ”John",
lastName: “Smith”,
address: “52 Vanderbilt Ave.”,
homePhone: “123-456-7890”,
workPhone: “897-389-8987”,
openDate: ISODate("2013-02-15 10:00”)
…
}
> db.accts.find( { accountID: 9874983789} )
Bank Account JSON Document

21. 21
{
_id : ObjectId("4e2e3f92268cdda473b628f6"),
policyNumber: 2398439343,
policyType: “Homeowners”,
firstName : ”John",
lastName: “Smith”,
address: “52 Vanderbilt Ave.”,
homePhone: “123-456-7890”,
workPhone: “897-389-8987”,
openDate: ISODate("2013-02-15 10:00”)
…
}
> db.policies.find( { lastName: “Smith”}
address: “52 Vanderbilt Ave.” )
P&C Policy Document

22. 22
{
_id : ObjectId("4e2e3f92268cdda473b628f6"),
accountID: 9874983789,
accountType: “Checking”,
firstName : ”John",
lastName: “Smith”,
address: “52 Vanderbilt Ave.”,
contactMethods: {
mobile: “389-897-8987”,
home: “983-893-3873”,
email: “john.smith@abc.com”,
work: “298-389-8983” }
openDate: ISODate("2013-02-15 10:00”)
…
}
> db.accts.find( { “contactMethods.mobile”: “983-893-3873” } )
Bank Account JSON Document

23. 23
{
_id : ObjectId("4e2e3f92268cdda473b628f6"),
accountID: 9874983789,
accountType: “Checking”,
ownershipType: “Joint”
accountOwners: [
{ firstName : ”John",
lastName: “Smith”,
address: “52 Vanderbilt Ave.”, …},
{ firstName : ”Anne",
lastName: “Smith”,
address: “52 Vanderbilt Ave.”, …} ]
openDate: ISODate("2013-02-15 10:00”)
…
}
> db.accts.find( { accountOwners: {$elemMatch: {
lastName: “Smith”,
address: “52 Vanderbilt Ave.”}}} )
Joint Bank Account Document

24. 24
{
_id : ObjectId("4e2e3f92268cdda473b628f6"),
sourceIDs: {
ABCSystemIDPart1: 8397897,
ABCSystemIDPart2: 2937430,
ABCSystemIDPart3: 932018 }
accountType: “Checking”,
accountOwners: [
{ firstName : ”John",
lastName: “Smith”,
contactMethods: [
{ type: “phone”, subtype: “mobile”, number: 8743927394},
{ type: “mail”, address: “58 3rd St.”, city: …} ]
possibleMatchCriteria: {
govtID: 2938932432, fullName: “johnsmith”, dob: … } },
{ firstName : ”Anne",
maidenName: “Collins”,
lastName: “Smith”, …} ],
openDate: ISODate("2013-02-15 10:00”),
accountFeatures { Overdraft: true, APR: 20, … }
}
General document per customer per
account
OR creditCardNumber: 8392384938391293
OR mortgageID: 2374389
OR policyID: 18374923

25. Querying for Single View

26. 26
Index any fields: arrays, nested, etc
// Compound indexes
> db.accts.ensureIndex({accountID: 1, lastName:1})
// Index on embedded docs and arrays
>db.accts.ensureIndex( {contactMethods.mobile: 1})
// Index on any depth
> db.accts.ensureIndex( {―owners.matchcriteria.ssn‖: 1} )
// Full text search
> db.accts.ensureIndex ( { address1: ―text‖,
address2: ―text‖ } )

27. 27
Query For First Product and Then All
// Customer knows his/her account number
> db.accts.find( {accountNumber: 9789732839} )
// Use looked up account to find other accounts
db.accts.find( {matchCriteria.ssn: 8973829438} )
// In reality, it’s more complicated
> db.accts.find({
$or: [ {mc.fullName: ―johnsmith‖, mc.dob: ―01/01/1970‖},
{mc.ssn: 8923784789},
{mc.homePhone: 29838923845}, … ] })

28. 28
Query For All Products Without ID
// Customer only knows phone number
> db.accts.find({ contactMethods.number: 9789732839
lastName: ―Smith‖ } )
// Confirm correct result w/ customer, then pull all accounts
// Same query as before to pull all accounts
> db.accts.find({
$or: [ {mc.fullName: ―johnsmith‖, mc.dob: ―01/01/1970‖},
{mc.ssn: 8923784789},
{mc.homePhone: 29838923845}, … ] })

29. 29
Text Search Example
(e.g. address typo so do fuzzy match)
// Text search for address filtered by first name and NY
> db.ticks.runCommand(
―text‖,
{ search: ―vanderbilt ave. vander bilt‖,
filter: {name: ―Smith‖,
city: ―New York‖} })

30. 30
• Custom application code
– Run your queries, compute your results
• Aggregation framework
– Declarative, pipeline-based approach
• Native Map/Reduce in MongoDB
– Javascript functions distributed across cluster
• Hadoop Connector
– Offline batch processing/computation
Analyzing/Aggregating Options

31. 31
//Find total value of each customer’s accounts for a given RM (or Agent) sorted by value
db.accts.aggregate(
{ $match: {relationshipManager: ―Smith‖}},
{ $group :
{ _id : ―$ssn‖,
totalValue: {$sum: ‖$value‖} }},
{ $sort: { totalValue: -1}} )
Aggregate: Total Value of Accounts

32. Why MongoDB is Most Capable?

33. 33
Single View of a Customer –
Why MongoDB?
 Dynamic schema => can handle vastly different data together and
can keep improving and fixing issues over time easily
 High scale/performance => directly impacts customer experience or
CSR MTTR so every second counts
 Auto-sharding => can automatically add processing power as
customers and products are added
 Rich querying => supporting ends users directly requires multiple
ways of access and key/value is not sufficient
 Aggregation framework => database-supported roll-ups for analysis
on data hub for customer information by marketing, sales, etc.
 Map-reduce capability (Native MR or Hadoop Connector) => batch
analysis looking for patterns and opportunities in data hub

34. 34
Why [Not] an RDBMS
• Dynamic schema => can handle vastly different data and can keep
improving and fixing issues over time easily
• High scale/performance => directly impacts customer experience or
CSR MTTR so every second counts
• Auto-sharding => can automatically add processing power as
customers and products are added
 Rich querying => supporting ends users directly requires multiple
ways of access and key/value is not sufficient
 Aggregation framework => database-supported roll-ups for analysis
on data hub for customer information by marketing, sales, etc.
 Map-reduce capability (Native MR or Hadoop Connector) => batch
analysis looking for patterns and opportunities in data hub

35. 35
Why [Not] Other NoSQL DBMSs
 Dynamic schema => can handle vastly different data and can keep
improving and fixing issues over time easily
 High scale/performance => directly impacts customer experience or
CSR MTTR so every second counts
 Auto-sharding => can automatically add processing power as
customers and products are added
• Rich querying => supporting ends users directly requires multiple
ways of access and key/value is not sufficient
• Aggregation framework => database-supported roll-ups for analysis
on data hub for customer information by marketing, sales, etc.
 Map-reduce capability (Native MR or Hadoop Connector) => batch
analysis looking for patterns and opportunities in data hub

36. Summary of Value

37. 37
Before MongoDB Solution
CSR Application
CSR Application
CSR Application
CSR Application
CSR Application

38. 38
With MongoDB Solution
CSR Application
Single Customer Portal

39. 39
1. CSR Application
– Minimize calls routed to other call centers
– Shorter MTTR because CSR has all information
– More efficient staffing because can pool CSRs better
– More effective cross-sell/upsell
– Better customer satisfaction
2. Customer portal
– Minimize calls needed at all
– Better customer service
– More effectively cross-sell/upsell
Short-term Value over the Long-Term

40. 40
3. Regulatory Compliance Initiative
– Minimize KYC or other regulatory risks
– Turn compliance costs into costs savings or revenue
generation
4. Marketing
– Analyze buying patterns more completely
– Target much more accurately for better results
5. Relationship Manager or Agent Application
– Effectively cross-sell/upsell and increase wallet
share
– Provide better, more complete customer service
Short-term Value over the Long-Term

41. 41
• MongoDB is the most capable for a single view of a
customer
• Dynamic schema can handle data from numerous
different systems all in one place
• Fast, flexible querying, analysis, & aggregation is
necessary to get maximum value
• High performance both on a single machine and
automatically across a cluster by auto-sharding
• MongoDB has all these features with low TCO
• 10gen has helped others with this and can help you
Summary

42. 42
Resource Location
MongoDB Downloads www.mongodb.org/download
Free Online Training education.10gen.com
Webinars and Events www.10gen.com/events
White Papers www.10gen.com/white-papers
Customer Case Studies www.10gen.com/customers
Presentations www.10gen.com/presentations
Documentation docs.mongodb.org
Additional Info info@10gen.com
For More Information
Resource User Data Management

43. How Capital Markets Firms Use
MongoDB as a Tick Database
Matt Kalan, Sr. Solution Architect
Email: Matt.kalan@10gen.com
Twitter: @matthewkalan