Huge upheaval in the finance industry has led to a major strain on existing IT infrastructure and systems. New finance industry regulation has meant increased volume, velocity and variability of data. This coupled with cost pressures from the business has led these institutions to seek alternatives. Top tier institutions like MetLife have turned to MongoDB because of the enormous business value it enables.
In this session, hear how MongoDB enabled these successful real world examples:
Single View of a Customer - 3 months and $2M for a single view of a customer across 50 source systems
Reference Data Management - $40M in cost savings from migrating to MongoDB for reference data management
Private cloud - MongoDB as a PaaS across a tier 1 bank for enabling agility for operations, not just the developer
The use cases are specific to financial services but the patterns of usage - agility, scale, global distribution - will be applicable across many industries.
Transcript: #StandardsGoals for 2024: What’s new for BISAC - Tech Forum 2024
Driving Business Value in FS with MongoDB
1. Driving Business Value in FS
with MongoDB
Matt Kalan, FS Solutions Architect
Email: Matt.kalan@10gen.com
Twitter: @matthewkalan
2. 2
• FS today requires agility, productivity, and low TCO
• RDBMS not supporting requirements well
• MongoDB built for these requirements
• MongoDB has hit critical mass in adoption
• Many valuable case studies in FS
• We can help you get started
Executive Summary
3. 3
Trends in FS Driving Change
Mobile &
Gamification (retail)
New
Opportunities
Regulations
Enhanced Risk
Management
CCP
Central
Clearing
Cost
pressures
4. 4
Requirements
• Aggregate disparate
data
• Change apps quickly
• Analyze data faster
• Store more data
• Increase productivity
• Reduce TCO
drastically
Putting Urgency on These IT
Requirements Like Never Before
5. 5
Unfortunately, RDBMSs Not Built for
These Requirements
Data Types & OOP
• Unstructured data
• Semi-structured
data
• Polymorphic data
Volume of Data
• Petabytes of data
• Trillions of records
• Tens of millions of
queries per second
Agile Development
• Iterative
• Short development
cycles
• New workloads
New Architectures
• Horizontal scaling
• Commodity
servers
• Cloud computing
6. 6
• Customfield1…100 or separate tables
• Caching & ORMs
• Expensive hardware and storage
• Data migration
• One schema across apps
• Application-specific partitioning
• Use files instead of databases
• Schema change takes 6 months
As a Result, Shoehorn Requirements
Slow time-to-market
Agility lost
High cost
Business frustrated
7. 7
Now There Is Help
2010
RDBMS
Key-Value/
Column Store
OLAP/BI
Hadoop
2000
RDBMS
OLAP/BI
1990
RDBMS
Operational
Data
Datawarehouse
Document DB
NoSQL
8. 8
What Requirements Are Needed to
Address These Challenges
Addresses Requirement Description
Data Types Hierarchical data
structure
Can match the structure of objects in today’s OOP languages
Data Types,
Agile
Dynamic schema Can handle differently shaped data in a table/collection and
not a predefined schema
Agile Native OOP
language
Keeps developers in one environment and encapsulates
functionality/validation/rules in one place
Volume Scale Can efficiently handle 100s tera & petabytes of data
Volumes, New
Arch
Performance High throughput on a single node and scales horizontally
easily
Still req Software cost Open source with premium value added services
Still req Data consistency How soon you can read data that was just written
Still req Rich querying Querying based on any field, e.g. secondary indexes
Still req Ease of use Short learning curve and easy to design
9. 9
How Databases Stack Up
Requirement RDBMS MongoDB Key/value Wide column
Hierarchical
data structure
Poor Great Poor OK
Dynamic
schema
Poor Great Poor OK
Native OOP
language
Poor Great Great Great
Scale Poor Great Great Great
Performance Poor Great Great Great
Software cost Poor Great Great Great
Data
consistency
Great OK Poor Poor
Rich querying Great OK Poor Poor
Ease of use OK Great OK Poor
10. 10
What Is Needed to Be Effective
Broadly
Requirement RDBMS MongoDB Key/value Wide column
Hierarchical
data structure
Poor Great Poor OK
Dynamic
schema
Poor Great Poor OK
Native OOP
language
Poor Great Great Great
Scale Poor Great Great Great
Performance Poor Great Great Great
Software cost Poor Great Great Great
Data
consistency
Great OK Poor Poor
Rich querying Great OK Poor Poor
Ease of use OK Great OK Poor
12. 12
Relational: All Data is Column/Row
Customer ID First Name Last Name City
0 John Doe New York
1 Mark Smith San Francisco
2 Jay Black Newark
3 Meagan White London
4 Edward Daniels Boston
Account Number Branch ID Account Type Customer ID
10 100 Checking 0
11 101 Savings 0
12 101 IRA 0
13 200 Checking 1
14 200 Savings 1
15 201 IRA 2
13. 13
Have to Manage Change in 3 Places
Relational
Database
Object Relational
Mapping
Application
Code XML Config DB Schema
14. 14
Instead Match the Data in your
Application
Relational MongoDB
{ customer_id : 1,
first_name : "Mark",
last_name : "Smith",
city : "San Francisco",
accounts : [ {
account_number : 13,
branch_ID : 200,
account_type : "Checking"
},
{ account_number : 14,
branch_ID : 200,
account_type : ”IRA”,
beneficiaries: […]
} ]
}
15. 15
Instead Put Data Model in One Place
Application
Code
Relational
Database
Object Relational
Mapping
XML Config DB Schema
Application
Code
Rich
Queries
Geospatial
Text Search
Map Reduce
Aggregatio
n
16. 16
No SQL But Still Flexible Querying
MongoDB
{ customer_id : 1,
first_name : "Mark",
last_name : "Smith",
city : "San Francisco",
accounts : [ {
account_number : 13,
branch_ID : 200,
account_type : "Checking"
},
{ account_number : 14,
branch_ID : 200,
account_type : ”IRA”,
beneficiaries: […]
} ]
}
Rich Queries
• Find all Mark’s accounts
• Find everybody who opened an account
last month
Geospatial
• Find all customers that live within 10
miles of NYC
Text Search
• Find all tweets that mention the bank
within the last 2 days
Aggregation
• What’s the average value of Mark’s
accounts
Map Reduce
• How many customers that have a
checking account also have an IRA
18. 18
70%+ Lower TCO
Commercial RDBMS
Compute – Scale-Up Servers
Storage – SAN
Dev. and Admin
Compute – Commodity HW
Storage – Local Storage
Dev. and Admin
$1,680K
$517K
19. 19
• MetLife Leapfrogs Insurance Industry with MongoDB-Powered
Big Data Application
– “innovative customer service application…in 90 days…from 70+ existing systems”
• 10gen Establishes Financial Services Advisory Group
– “ten leading global institutions…including Barclays, Goldman Sachs and MetLife.”
• IBM and 10gen Collaborate to Bring Mobile to the Enterprise
– “IBM will standardize on BSON, MongoDB wire protocol and query language”
• Informatica and 10gen Partner to Expand Data Integration for
MongoDB
– “use PowerCenter Big Data Edition to access…data stored in the market's leading
NoSQL database”
Customers and Software
Heavyweights Support MongoDB
20. 20
10gen Snapshot
250+ employees 600+ customers
Over $81 million in funding
Offices in New York, Palo Alto, Washington
DC, London, Dublin, Barcelona and Sydney
21. 21
Common FS Use Cases
Capital Markets
1. Reference Data
Management
2. Risk Analysis &
Reporting
3. Private DBaaS
4. Buy-Side Portal
5. Regulatory Reporting
6. Tick Data Capture &
Analysis
7. Trade Repository
8. 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
22. 22
Common FS Use Cases
Capital Markets
1. Reference Data
Management
2. Risk Analysis &
Reporting
3. Private DBaaS
4. Buy-Side Portal
5. Regulatory Reporting
6. Tick Data Capture &
Analysis
7. Trade Repository
8. 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
23. 23
Distribute reference data globally in real-time for
fast local accessing and querying
Reference Data Case Study:
Global investment bank
Problem Why MongoDB Results
• Delays up to 36 hours in
distributing data by batch
• Charged multiple times
globally for same data
• Incurring regulatory
penalties from missing
SLAs
• Had to manage 20
distributed systems with
same data
• Dynamic schema: easy to
load initially & over time
• Auto-replication: data
distributed in real-time,
read locally
• Both cache and database:
cache always up-to-date
• Simple data modeling &
analysis: easy changes
and understanding
• Will save about
$40,000,000 in costs and
penalties over 5 years
• Only charged once for data
• Data in sync globally and
read locally
• Capacity to move to one
global shared data service
24. 24
Previous Reference Data Management
Architecture
Feeds & Batch data
• Pricing
• Accounts
• Securities Master
• Corporate actions
Source
Master Data
(RDBMS)
Batch
Batch Batch
Batch
Batch
Batch
Batch
Destination
Data
(RDBMS)
Each represents
• People $
• Hardware $
• License $
• Reg penalty $
• & other downstream
problems
25. 25
Solution with MongoDB
Feeds & Batch data
• Pricing
• Accounts
• Securities Master
• Corporate actions
Real-time
Real-time Real-time
Real-time
Real-time
Real-time
Real-time
Each represents
• No people $
• Less hardware $
• Less license $
• No penalty $
• & many less
problems
MongoDB
Secondaries
MongoDB
Primary
26. 26
Global 360 degree view of customers’ policy portfolio
and interactions
Single View of Customer Case Study:
Tier 1 Global Insurance Provider
Problem Why MongoDB Results
• 70 systems and 20
screens to view
customer policies
• Many CSR calls taken
just to reroute customer
• Poor customer
experience
• Source systems are
hard to change
• Dynamic schema: can
combine 70 systems
easily
• Performance: can handle
all data in one DB
• Replication: local reads
and high availability
• Sharding: can add data
easily by scaling out
• Delivered in 3 months
with $4M – previous
attempts failed with $25M
• Unified customer view
available to all channels
• Shorter and less calls re-
routed
• Increased customer
satisfaction
27. 27
Single View of Customer Case Study:
Tier 1 Global Insurance Provider
Source
database 1
Source
database 2
…
Source
Database 70
Custom app
exports JSON
Document
• per product
• per customer
CSR Application
Customer
Application
Agent/RM
Application
OLTP/real-time
access
Future phases
Queue to Update
Source Systems
28. 28
Enable a globally distributed, centrally managed private
data cloud with optional persistence framework
DBaaS Case Study:
Global investment bank
Problem Why MongoDB Results
• Wanted app groups to
focus on building apps,
not data access logic
• Horizontal scaling done
by each application
• Up to 6 months for app
groups to procure
hardware
• Each phase has
hardware procurement
• Native language drivers:
groups can focus on agile
application development
• Auto-replication: data
distributed globally in real-
time
• Auto-sharding: linearly
scale automatically
• Time to market decreased
by at least 50%
• Object persistence
included in framework
• DB capacity added in
minutes not months
• Same environment from
prototype to production
29. 29
Risk Analytics & Reporting
Use case requirements:
• Collect positions, pricing, ratings, and other source data
• Calculate risk metrics and exposures
• Handle high throughput for intraday metrics or large simulations
• Be highly available so can be relied on
Why MongoDB?
• Dynamic schema => data can be collected from many different sources and
formats without time delays for data modeling and schema changes
• High throughput => more up-to-date data or high volumes
• Aggregation framework => database-supported roll-ups from various desks,
asset classes/products, geographies, etc.
• Map-reduce capability (Native MR or Hadoop Connector) => perform
batch risk analysis and simulations
31. 31
Online Banking/Trading Portal
Use case requirements:
• Store portfolios, accounts, positions/balances, orders, market values, etc.
• Ad hoc querying by account, security, date, trader, thresholds, etc.
• Fast response times and iteration keep customer satisfaction high
• Relationship manager wants real-time reporting and alerting on customer
activity
Why MongoDB?
• Low latency & caching => fast response times for all data available
• Dynamic schema => Can handle any portfolio structure, assets, or accounts
• High scalability => Reporting requirements on often large customer data
sets
• Aggregation Framework => calculate metrics, aggregations, and analysis
32. 32
• FS today requires agility, productivity, and low TCO
• RDBMS not supporting requirements well
• MongoDB addresses all these requirements as a general
purpose operational DB
• MongoDB has hit critical mass in adoption
• Many case studies demonstrating value in FS
• Let us know if we can help you get started
Summary
33. 33
Subscriptions
Professional Support, Subscriber Edition and Commercial License
10gen Products and Services
Consulting
Expert Resources for All Phases of MongoDB Implementations
Training
Online and In-Person for Developers and Administrators
34. 34
Resource Location
MongoDB Downloads 10gen.com/download
Free Online Training education.10gen.com
Webinars and Events 10gen.com/events
White Papers 10gen.com/white-papers
Case Studies 10gen.com/customers
Presentations 10gen.com/presentations
Documentation docs.mongodb.org
Additional Info info@10gen.com
For More Information
Resource Location
Editor's Notes
Mention FS includes cap markets, banking, and insurance. Looking at attendees, cap markets most but also touch on insurance and banking
Reg- Cap markets – uncertainty plus changing regs with Dodd-Frank, Basel III, Volkor, etc. More regulatory reporting demands as GreatBanking – pressure from the fed for reportings, TBTFRisk mgmt – financial crisis showing failure of risk mgmt, so changing analytics, and the drive to be intraday, take more factors into accountCost pressure – esp. banking with low interest rates and fees
Bringing data together (regulatory, risk, trade repository, etc.) painful with RDBMS => polymorphicAgility to change systems generally is painful => agileRun risk analysis more often towards intraday => performanceStore many years of audit info cheaply but online => scaleData warehouse not timely or performant enough => performanceStuck in expensive contracts without leverage => cost
RDBMSs built before OOP, agile, cloud, and big dataData types – social networking and IM compliance; multiple desks, products, geographiesVolumes – store and analyze more data than ever for auditing and risk esp. and at low cost; data warehouse has some data but not how you want it and performant enough