Webinar: How Financial Firms Create a Single Customer View with MongoDB
Download as PPTX, PDF•7 likes•3,612 views
The document outlines how financial firms can leverage MongoDB to create a single customer view, detailing its benefits such as dynamic schema, high scalability, and rich querying capabilities. It includes a case study of MetLife utilizing MongoDB for improved customer service and operational efficiency, resulting in significant cost reductions. The text emphasizes MongoDB's suitability over traditional RDBMS and other NoSQL solutions for managing diverse data and providing comprehensive customer insights.
![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](https://image.slidesharecdn.com/singleviewofacustomer2013may-130523134342-phpapp02/85/Webinar-How-Financial-Firms-Create-a-Single-Customer-View-with-MongoDB-23-320.jpg)
![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](https://image.slidesharecdn.com/singleviewofacustomer2013may-130523134342-phpapp02/85/Webinar-How-Financial-Firms-Create-a-Single-Customer-View-with-MongoDB-24-320.jpg)
![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}, … ] })](https://image.slidesharecdn.com/singleviewofacustomer2013may-130523134342-phpapp02/85/Webinar-How-Financial-Firms-Create-a-Single-Customer-View-with-MongoDB-27-320.jpg)
![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}, … ] })](https://image.slidesharecdn.com/singleviewofacustomer2013may-130523134342-phpapp02/85/Webinar-How-Financial-Firms-Create-a-Single-Customer-View-with-MongoDB-28-320.jpg)
![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](https://image.slidesharecdn.com/singleviewofacustomer2013may-130523134342-phpapp02/85/Webinar-How-Financial-Firms-Create-a-Single-Customer-View-with-MongoDB-34-320.jpg)
![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](https://image.slidesharecdn.com/singleviewofacustomer2013may-130523134342-phpapp02/85/Webinar-How-Financial-Firms-Create-a-Single-Customer-View-with-MongoDB-35-320.jpg)
Webinar: How Financial Firms Create a Single Customer View with MongoDB
- 1. How Financial Firms Create a Single Customer View with MongoDB Matt Kalan, FS Solutions Architect Email: [email protected] 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
- 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: “[email protected]”, 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 [email protected] For More Information Resource User Data Management
- 43. How Capital Markets Firms Use MongoDB as a Tick Database Matt Kalan, Sr. Solution Architect Email: [email protected] Twitter: @matthewkalan
Editor's Notes
- #6: Mention tick databases
- #7: Fewer reads, data is together, memory mapped files, caching handled by OS, naturally leaves most frequently accessed data in RAM (have enough RAM to fit indexes and working data set into RAM for best performance), horizontal scaling is "built-in" to the product by design from the start.
- #20: JSON document – contains key value pairs, different types, values can also be arrays and other documents
- #21: JSON document – contains key value pairs, different types, values can also be arrays and other documents
- #22: JSON document – contains key value pairs, different types, values can also be arrays and other documents
- #23: JSON document – contains key value pairs, different types, values can also be arrays and other documents
- #24: JSON document – contains key value pairs, different types, values can also be arrays and other documents
- #25: JSON document – contains key value pairs, different types, values can also be arrays and other documents