OmniMarkets - White Paper - Model Risk Management

Pierre Leignadier / Yihui Zhang OMNIMARKETS, LLC | 160 BROADWAY, SUITE 700, NEW YORK, NY 10038, USA

Model Risk Management BEST PRACTICES FOR TODAY AND TOMORROW

November 2016.

Model Risk Management. Best Practices for today and tomorrow.

1 OmniMarkets, LLC.

Abstract

We review the development of model risk management against the backdrop of

the growing importance of models in the financial industry, in terms of number,

use and complexity. Our collective understanding of the means to mitigate model

risk have evolved and so has the regulations. The first publication on the matter

(OCC 2000-16) focuses on Model Validation mainly, ten years later it was followed

by a more comprehensive set of guidance and recommendations (OCC 2011-12 /

SR 11-7) “Supervisory Guidance on Model Risk Management”. Model Risk

Management (“MRM”) is still maturing today but its importance will undoubtedly

continue to grow; so we have sought to extract the best lessons applicable today as

well as to peek into the future.

Disclaimer

All of the views, opinions and interpretations presented herein are solely those of

OmniMarkets and should not in any way be considered to represent those of the

Office of Comptroller of the Currency or of the Federal Reserve.


2 OmniMarkets, LLC.

Table of Contents

Abstract ....................................................................................................................... 1

Disclaimer ................................................................................................................... 1

Table of Contents ........................................................................................................ 2

Introduction ................................................................................................................ 3

1 Regulatory Requirements and Best Practices..................................................... 4

1.1 Bulletin OCC 2000-16: a new millennium for Model Risk Management ..... 4

1.1.1 Key points of OCC-2000 ........................................................................... 4

1.1.2 Sound Model Validation policy ............................................................... 5

1.1.3 Model Validation procedure ................................................................... 6

1.2 OCC Bulletin 2011-12 replaces 2000-16 – Key points: ................................. 8

1.2.1 OCC 2011-12/SR 11-7 - The role of Internal Audit .................................. 8

1.2.2 Model Validation – Best practice elements ............................................ 9

2 Model Risk Management today ....................................................................... 10

2.1 Model development ................................................................................... 10

2.2 Model Validation ........................................................................................ 10

2.3 On-going monitoring .................................................................................. 10

2.4 Models Inventory ....................................................................................... 11

3 Raising the bar: “M” is for Management .......................................................... 12

3.1 Holistic MRM .............................................................................................. 12

3.2 Governance = workflows ........................................................................... 14

3.3 Interactions between models .................................................................... 14

4 Quantifying Model Risk .................................................................................... 16

4.1 Measurement of MRM – 1st Generation: KPI ............................................. 16

4.2 Measurement of MRM – 2nd Generation: PE, EAE and LGE ..................... 16

References ................................................................................................................ 18

OmniMarkets – Senior Team .................................................................................... 19


3 OmniMarkets, LLC.

Introduction

The concept of Model Risk, the need for its recognition and management did not

really exist prior to the 1990’s. This is understandable, as any model error made by

a person could only have a (very) limited impact and hence, there was no real

model risk per se. The advent of computers in banks changed that forever. The

same model, the very same algorithm is now being used a staggering amount of

times, with ever increasing volumes and more and more automation (increasing

the multiplying effect of any error even more). The Office of the Comptroller of the

Currency writes in year 2000: “Computer models are increasingly used in banking to

estimate risk exposure, analyze business strategies and estimate fair values of

financial instruments and acquisitions. As models play an increasingly important

role in decision-making processes, it is critical that bank management reduce the

likelihood of erroneous model output or incorrect interpretation of model results.

The best defense against such "model risk" is the implementation of a sound model

validation framework that includes a robust validation policy and appropriate

independent review.”1.

As we know, since then, this trend has only increased.

The financial instruments being intermediated are ever more complex and so are

the models used to evaluate their value or the risks borne. Moreover, gut-feeling

and expert judgement alone cannot suffice to understand these risks and manage

them objectively and reliably, so, still more models are used to assist the decision

making and management. However, this extensive use of models and complex

models comes with model risk, and as any risk, model risk needs to be managed.

The industry and the regulators first focused on model validation to mitigate this

risk. With time, a deeper understanding as lead to a more comprehensive

approach and set of remedies: Model Risk Management.

In this paper, we give the key points and best practices issued from the published

regulations. Both are relevant and OCC 2011-12 (SR 11-7)2 is building on OCC 2000-

16, we introduced them in chronological order to illustrate the evolution. We also

draw a picture of the state of Model Risk Management in the financial industry

based on our experience and we then present how -we believe- a modern Model

Risk Management framework should be designed today. Finally, we peek into the

future and propose a path to address the remaining frontier: the measurement – or

quantification - of Model Risk.

1 Bulletin OCC 2000-16, now rescinded. It can still be found at: https://www.occ.gov/static/news-issuances/bulletins/rescinded/bulletin-2000-16.pdf 2 Joint publication: Board of Governors - Federal Reserve / OCC: SR 11-7 or OCC 2011-12: https://www.federalreserve.gov/bankinforeg/srletters/sr1107a1.pdf

https://www.occ.gov/static/news-issuances/bulletins/rescinded/bulletin-2000-16.pdf

https://www.federalreserve.gov/bankinforeg/srletters/sr1107a1.pdf


4 OmniMarkets, LLC.

“An effective model

validation process must

address all three

components.”

OCC 2000-16.

1 Regulatory Requirements and Best Practices

Model risk can never be completely eliminated, but in the late 90’s the concept of

model validation started quickly to take hold as a primary means to mitigate model

risk. These efforts were often isolated and uneven, as they did not follow any

industry standards. This all changed with the publication of Bulletin OCC 2000-16

by the Office of the Comptroller of the Currency (“OCC”) on May 30, 2000. About

10 years later, building on the lessons learned, this first landmark bulletin was

replaced in April 2011 by the joint release by the OCC and the Federal Reserve

Board (“FRB”): OCC 2011-12 or SR 11-7. The following seeks to extract the key

points of these 2 bulletins and the best practices for a sound and compliant Model

Risk Management.

1.1 Bulletin OCC 2000-16: a new millennium for Model Risk

Management

The OCC published its landmark bulletin at the start of the new millennium and

changed MRM forever by defining the requirements for model validation and

setting the baseline standard for validation.

1.1.1 Key points of OCC-2000

Definition of the 3 core components of a “model”:

An information input component, which delivers assumptions and data to

the model

A processing component, which contains the theoretical model and

transforms inputs into estimates via computer instructions (i.e. code)

A reporting component, which translates the mathematical estimates into

useful business information


5 OmniMarkets, LLC.

“The personnel performing

model validation should be

as independent as possible

from the personnel who

construct the model.”

OCC 2000-16.

3 generic procedures for Model Validation are defined:

independent review of the logical and conceptual soundness

comparison against other models (Benchmarking)

comparison of model predictions with ‘reality’ (market prices, back-

testing)

OCC 2000-16 put forward Elements of Sound Validation Policy. These

elements emphasize the importance and requirement of independent review.

It also includes a requirement for model documentation “that is sufficiently

detailed to allow the precise replication of the model being described.”

OCC 2000-16 also identified three lines of defense against model risk that had

to be in place:

First Level: Testing performed by model developers. This is the testing

done by developers to check their assumptions, their implementation

and their results to ultimately grow comfortable that their model is

performing as it was intended.

Second Level: independent model validation and testing. Validators

should first review and assess the developers’ documentation and

testing and then also perform additional independent testing.

Third Level: Internal Audit’s review. The Audit’s role is to assess

developers and the validators played their part correctly, i.e. in

accordance with the official policy and procedure documents defining

the firm’s requirements for the 1st and 2nd Level. The policy and

procedures must also be compliant (with OCC 2000-16 / OCC 2011-12).

1.1.2 Sound Model Validation policy OCC 2000-16 mentions that validation policy should help ensure the model-

validation efforts are consistent with senior management’s view regarding the

proper trade-off between costs and benefits. The policy thus includes the following

elements:

Independent Review:

The personnel performing model validation should be as

independent as possible from the personnel constructing the

model

Validation policy should provide for as independent a review as

practicable, and can be complemented by external reviewers or

internal audit

When comprehensive independence is not practicable, the policy

should explicitly provide for an effective communication process

between modelers and decision makers


6 OmniMarkets, LLC.

Defined responsibilities

The responsibility for model validation should be formalized, and before a

model can enter production the following units should be specified by

senior management:

the independent model-validation unit or external reviewer must

document the model validation tests and the reasons for

concluding that the model is valid

internal audit must verify that no models enter production without

formal approval by the validation unit.

Model documentation

At the organization level, a catalogue of models and their

applications should be maintained.

The most rigorous policies demand documentation detailed to a

level sufficient to allow the precise replication of the model.

Ongoing Validation

Best practices for validation policies require that all changes in the

modeling process be documented and submitted for independent

review.

A useful practice is to allow model changes only periodically, and

only after independent review and approval by the appropriate

level of the bank’s decision makers.

Models should be subjected to change-control procedures, so that

code cannot be altered except by approved parties.

Internal Audit Oversight

1.1.3 Model Validation procedure Below are the key steps of a sound model validation procedure:

Validate the model Input Component:

If the data comes from internal sources, the audit functions need

to ensure it is consistent with other uses (e.g. General Ledger)

If the data originates from external providers, it needs to be

checked against alternative sources.

Models may have dependencies between each other, i.e. some

inputs may be the output of other models (e.g. yield curves or

volatility surfaces)

Validate the model’s underlying assumptions: Assumptions should be

validated with respect to whether it is valid for the model’s intended use.


7 OmniMarkets, LLC.

Important behavioral assumptions should be routinely compared to actual

portfolio behaviors.

Validate the model’s quantitative components. A central point of the

model validation is the independent review of the conceptual soundness of

the model. The underlying theory and mathematical methodologies

employed by the developers need to be validated for soundness and

acceptance by others (practitioners, academia . . .). Comparing the model

to well-accepted alternative models (benchmarks) is often useful and may

reveal weaknesses or limitations.

Verify the model’s implementation into production code. OCC/FRB

standards require validators to not just assess the appropriateness of the

model for its intended application, but also to verify that the model is

correctly implemented in production. Well-validated “benchmark” models

are often used for many types of pricing and curve construction

applications, but not generally for risk models. We know of three basic

approaches to verifying implementation of a model:

Line-by-line source code review. This is tedious and error-prone.

This can only be done for simple models with few lines of code.

Benchmarking against alternative similar validated models. This is

often the choice of validators because of speed but it opens the

door to residual differences.

Replication. This is of course the ‘real’ and best way, but a full

replication can be very time-consuming and even more to the point

it presumes a sufficiently detailed documentation.

Validate the model outputs. Validators need to assess how the model

estimates compare with other measurements: either market prices or

estimates from alternative well-accepted models. While this is often

possible for pricing models, risk models often require implementing

alternative models (benchmarks) because of lack of publicly available data.


8 OmniMarkets, LLC.

1.2 OCC Bulletin 2011-12 replaces 2000-16 – Key points:

As said, OCC 2011-12 (SR 11-7) builds on the earlier bulletin, adding some

requirements and providing a more comprehensive view of MRM, mirroring a

maturing understanding of MRM by the financial community.

Most noticeably:

• More detail is provided on the model review process and methodology

• It underscores the importance of independent validation, ongoing

monitoring and regular (annual) reviews.

• The role of internal audit is detailed in a new section (see below)

• It requires the validation of vendor and other 3rd party models

• It requires model stress-testing (previously absent)

1.2.1 OCC 2011-12/SR 11-7 - The role of Internal Audit We are quoting from the bulletin verbatim:

“Internal audit also has an important role in ensuring that validation work is

conducted properly and that appropriate effective challenge is being carried out. It

should evaluate the objectivity, competence, and organizational standing of the key

validation participants, with the ultimate goal of ascertaining whether those

participants have the right incentives to discover and report deficiencies. Internal

audit should review validation activities conducted by internal and external parties

with the same rigor to see if those activities are being conducted in accordance with

this guidance. Internal audit should verify that acceptable policies are in place and

that model owners and control groups comply with those policies. Internal audit

should also verify records of model use and validation to test whether validations

are performed in a timely manner and whether models are subject to controls that

appropriately account for any weaknesses in validation activities. Accuracy and

completeness of the model inventory should be assessed.”


9 OmniMarkets, LLC.

“One common misconception

is that validation of the

computer processing is not

necessary for vendor models,

because these models have

"met the market test." In fact,

banks that apply good

validation procedures to

vendor models often find

material processing errors.”

OCC 2000-16.

1.2.2 Model Validation – Best practice elements • Element 1: Make sure a model validation policy with clear responsibility

assignments and documentation procedures is in place

• Element 2: Ensure a well-documented model inventory is in place

• Element 3: Validations should be initiated with a request for documentation from

the model developers, and start with checking the document’s

completeness. Inadequate documentation may lead to a rejection of

validation request from senior management.

However, in practice, documentation is often either absent altogether

or incomplete. But rejecting a request for validation is rarely

feasible/practical nor desirable; however, this should be the stated

goal in terms of procedures and policies, in order to slowly change

behaviors and documentation does not remain an afterthought of

development.

• Element 4: The validation document should always cover information provided by

the model developers’ documents. This includes but not limited to the

reasoning for selecting the model, the data and assumptions used by

the model and the testing process of the model.

• Element 5: Stress-testing, as a newly added aspect in OCC 2011-12, should be put

in place to ensure the robustness of the model with various scenarios

• Element 6: Finally, prepare and issue a Model Validation Report that includes:

- An executive summary page with approval/disapproval status

(and limitations/restrictions) of the model clearly indicated.

- A conceptual assessment including an assessment of the

developer’s documentation (including development evidence and

testing), all theory, assumptions, mathematics . . .

- A technical assessment including implementation verification (by

independent replication, code review or benchmarking) and

additional independent testing (including stress testing, reverse

stress testing and back testing).

- A detailed section describing ‘effective challenges’ made by the

validators

- A final conclusion about the models’ appropriateness and

suitability for its intended application.

- A summary of any findings or shortcomings in the model that will

not cause the model to be failed but require remediation.

• Element 7: Prepare for examination. Validator should except the review of their

work by Internal Audit (3rd Level) and by the regulators, so all data,

documents, research documents, code, etc. . . . should be gathered

into a complete package to allow for a full independent review.


10 OmniMarkets, LLC.

2 Model Risk Management today

The regulations above are clear and SR 11-7 (OCC 2011-12) has been out for over

five years and the industry has made great progress towards compliance.

However, as always, changing people’s habits is hard – very hard - and it is slow.

Also, we are noting a big diversity in the progress depending on the size of the

institution (and the budgets/efforts invested) as well as on the various area of the

MRM.

2.1 Model development

The industry and quants have been familiar with model development for a very

long time. There is no real problem on the model development, per se, the only

issue is really the governance of the development and more specifically its

documentation. As the authority of Model Risk Managers increases, and rules &

procedures improve, we should note further progress and the acceptance that no

model development is complete absent a complete documentation.

2.2 Model Validation

Model Validation is another concept that the industry has found relatively easy to

grasp. The real issues here are more the scope (what needs to be validated?) as

well as the depth of the validations. Also, we find most of the focus is often

disproportionately put on the processing component of the models, without paying

sufficient attention both to the input component (calibrations, assumptions,

market data, . . .) as well as on the reporting component and its business usage.

Furthermore, due to incomplete (sometimes absent) documentation validators too

often rely on benchmarks, which are a convenient time-saving approach for the

replication step, but this approach does not bring the full value of an independent

replication (bug correction, documentation improvement, . . .).

2.3 On-going monitoring

This is an area where we find people still have issues understanding the regulation

or at least translating it into actions/procedures, hence this area is often

missing/omitted. “Model Risk on-going monitoring”? What does that mean?

The regulatory guidance provides us with the answer: “On-going monitoring”

means a ‘surveillance’ function to monitor any change in the circumstance of a

particular model, that is any change in the circumstance of any of the 3

components of a model:



Tests and checks should be put in place and run on a regular basis (frequency and

change events) to ensure that the reality of the model matches or is within the

bounds of the documented development, validation and audit, once the model is in

use (in production).

Any change in the model circumstance, in turn should trigger a documented

Review & Decision Step. The review may be very quick and the decision may be

that nothing needs to be done; or, on the contrary, the decision may be that a full

validation is warranted. Either way, good governance demands this Review and

Decision Step be made and documented.

2.4 Models Inventory

Following the recommendation of the regulation and drawing up the inventory is

really transformational for an organization. Indeed, it compels the organization to

view model risk, not as a series loosely connected mandatory tasks, procedures or

policies, but it brings everything together, it ‘glues’ everything together and allows

the organization to view model risk in a comprehensive (coverage) and a holistic

manner (actors, processes, tasks, policies).

The simple listing of the models is incredibly informational to an organization,

because it forces it to define the scope (what should be included?) as well as look

for long forgotten used models.

This simple piece of information will reveal a real map of where the organization

and a road map for management of what remains to be done. Immediate insights

will be available: how many models? How many external/internal? Can we

streamline our data and avoid redundancies or dangerous independent duplicates?

Overall, by bringing the first comprehensive view, the inventory of models used is

very transformational because the information it will reveal will undoubtedly

provide the impetus for change and improvement.



3 Raising the bar: “M” is for Management

The regulations pre-cited are clear and the implementation of the best practices is

a great step forward in order to mitigate Model Risk; however, they do not help the

risk manager actually manage this risk and the additional amount of tasks and work

they demand. The inventory is a very necessary step for MRM but it is not

sufficient for real management of the model risk.

Two additional layers are needed to help the risk manager with his daily

surveillance and management function: (1) a summary dashboard of the inventory

and (2) processes and procedures, to link all the different pieces of MRM

(development, implementation, validation, on-going monitoring, inventory)

together as well as with the set of tasks/actions that need to be completed in

relation to a change in the circumstance of any model.

Such a framework allows a horizontal (and aggregate) view of all the models, but it

can also be improved to allow for a vertical view across all the models and

businesses.

3.1 Holistic MRM

As previously noted, the various tasks of MRM are clearly defined and an inventory

of all the models is an essential part of modern MRM. However, to be really useful

and helpful to the risk manager, a higher level of information needs to be designed

for each MRM task allowing for global view, in a clear and simple dashboard:

summary information relating to the MRM element as well as an overall grade for

the element considered (development, implementation, validation . . .).

This summary information – MRM level information - needs to be designed

following the guidelines but, more importantly, following the specific

circumstances of the organization and in relation to its goals from an MRM level.

From experience, using something simple like traffic lights of grading from 1 to 5 is

the better way to go.

See next page for a graphical illustration (only 2 models).



Once in place, such MRM level information for all the elements brings new and

higher level information to the risk manager. For example, if traffic lights grading

was used, a dashboard can simply be designed to show:

- How many elements of MRM are in the Green? Yellow? Red?

- Inventory of models broken down along various axis: internal/external or

category of models (valuation, risk, liquidity, revenues, capital . . .)

- How many model validations need to be completed in the next month?

Quarter? Year?

- How many documentations are missing?

This view would of course provide great insights to the risk manager, the internal

audit and facilitate the reporting to the upper management.

General Information - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Development- - - - - - - - - - - - - - - -

Implementation- - - - - - - - - - - - - - - -

Validation- - - - - - - - - - - - - - - -

On-going monitoring- - - - - - - - - - - - - - - -

Internal Audit- - - - - - - - - - - - - - - -

General Information - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Development- - - - - - - - - - - - - - - -

Implementation- - - - - - - - - - - - - - - -

Validation- - - - - - - - - - - - - - - -

On-going monitoring- - - - - - - - - - - - - - - -

Internal Audit- - - - - - - - - - - - - - - -

Model #1

Documents, Reports, Code, Data, . . .





Model #2






Inventory

Summary information

and Scorecard

Full work products

package of MRM elements



3.2 Governance = workflows

Once the MRM framework described above is in place, simple workflows can be

put in place alongside alerts to transform the MRM framework into a real MRM

system/application. For example, an alert is being raised because the Point of

Contact (“POC”) for its Model Development task has left the organization and a

new POC needs to be designated and given that responsibility. Or the

automatically run tests & checks show a breach (data moved out of bounds) for

one of the levels of underlying assumptions; or the market has moved significantly

from the last calibration etc.

Naturally the action(s) that result from each event/alert need to be designed to be

fully adapted to the organization. Workflows basically translate the governance

around MRM into code.

3.3 Interactions between models

If the information at the MRM level is designed correctly, the inventory designed

above will also allow for the visualization of the interactions between models. For

example, the estimates generated by model X are used downstream for the input

of model Y (assumptions, calibration, prices . . .). This can potentially reveal hidden

or overlooked issues and, more importantly, it is essential information for the

validation and the on-going monitoring of model Y.

From these interactions, graphs of downstream dependencies originating from the

external data sources can be drawn (it would look like trees) and underscore their

respective importance or lack thereof. Once an organization finds that a single and

questionable data source is at the origin of multiple key estimates; the organization

may want to invest in this particular data, to multiply the sources or at least check

it more closely.



Similarly, upstream paths illustrating all the upstream dependencies of a particular

model will be able to be drawn:

As we have seen, true Management of Model Risk goes beyond following the best

practices of the various elements of MRM: development, implementation,

validation, on-going monitoring, inventory. It requires an additional layer of

indicators and processes to articulate the basic elements and allow for real

management. From our experience, this piece is often still missing and only the

major global banks have invested and made the effort to put such framework in

place. That being said, as the FRB raises the bar constantly, there is no doubt in our

minds that such MRM frameworks will become more widely implemented.

The final frontier for MRM is its quantification. After all, model risk is risk and, as

such, it should be measured (not just managed) and capital should be put aside to

account for its measure. Ideally its measure could be aggregated with the

measures of other types of risks. The industry is not there yet, but in the following

chapter we offer a potential path towards such measurement.



4 Quantifying Model Risk

MRM is Risk and as such in the end, the industry will need to start quantifying it

and account for it. In the end, what we ought to have is a measure that can be

integrated in the overall measure of risks a financial institution faces. How can this

be done practically today? What direction are we embarking on towards this goal?

4.1 Measurement of MRM – 1st Generation: KPI

As was done for operational risk, one approach to start quantifying Model Risk

would be to associate each MRM elements and sub-elements to Key Performance

Indicators (KPI’s). Here too, we think the best way to go is to keep things simple

with either traffic lights or 1 to 5 grading.

Depending on how it was designed, this most likely will require an increase in the

number of data points on the summary information (report card) for each element.

However, once in place, aggregations/statistics can then be made at different levels

and along different axis, to measure and analyze the model risk from various

angles. This would give an organization a first measurement and also an easy way

to track progress.

This first measurement could be improved by taking into account (weights) the

importance of the model being gauged: its materiality. Additional information (e.g.

complexity or uncertainties) can easily be added by simple questionnaire.

4.2 Measurement of MRM – 2nd Generation: PE, EAE and LGE

Again, taking as a model what has been done on the operational risk, one can

envision that before long banks and other financial institutions will anonymously

submit model risk incidents or errors. Naturally, the willingness of the industry to

share information about errors made remains to be seen, but this is a clear path

towards the quantification of Model Risk.

Once this data is available, the industry will undoubtedly model the Expected Loss

due to Model Risk in the a very familiar way:

𝐸𝐿 = 𝑃𝐸 × 𝐸𝐴𝐸 × 𝐿𝐺𝐸

EL: Expected Loss due to Model Risk error/incident

EAE: Exposure At Error (or incident). Basically the materiality of the model relating

to the error/incident.

LGE: Loss Given Error



With the adequate standardized data available3, given a certain state of its own

MRM, an organization will be able to easily infer the various values of the

equations above.

3 A similar endeavor was started for the sake of Operational Risk years ago by www.ORX.org and we expect the industry under the pressure of the regulators to launch a similar effort.

http://www.orx.org/



References

1. “Concepts to Validate Valuation Models”, P. Whitehead, in: “Risk Model

Evaluation Handbook”, G. Gregoriou, C. Hoppe and C. Wehn (Eds), 2010

2. “Understanding and Managing Model Risk”, Morini 2011

3. “Model Validation: theory, practice and perspectives”, Henaff 2012



OmniMarkets – Senior Team

Mr. Pierre Leignadier

Mr. Leignadier-Fahlström launched OmniMarkets in 2004. Prior to OmniMarkets,

he was the head of Scandinavian interest-rate derivatives trading at Svenska

Handelsbanken in London. He also headed the Securitized Credit Analytics team at

Calyon Americas. He was a derivatives trader and quantitative developer for

Banque Indosuez in Paris and Stockholm.

Mr. Leignadier-Fahlström has a Master of Philosophy in Quantitative Finance from

Ecole Normale Superieure de Cachan (France) and a Master in Biology and

Mathematics from Agro Paris-Tech, Institute National Agronomique Paris-Grignon

(France). His expertise includes trading, portfolio and risk management and

structured finance.

Mr. Yihui (Kevin) Zhang

Mr. Zhang is a Managing Director at OmniMarkets specializing in structured finance

and quantitative research and development. Prior to joining OmniMarkets, Mr.

Zhang was a statistical researcher at the Centre for Economic Development

Research in China and an equity analyst at CITIC Securities in Wuhan, China.

Mr. Zhang holds a MS in Economics from Wuhan University and a MS in Financial

Engineering from Claremont Graduate University, CA (USA). He also received a BS in

Automotive Engineering & Economics from Wuhan University of Technology, Mr.

Zhang’s expertise includes macro-economy, quantitative finance and statistical

analysis.

Mr. Robert Tian

Mr. Tian is OmniMarkets' Model Risk Management (MRM) Advisor. He is currently

the director of risk modeling at a regional bank in New England, managing a team

of quants to develop all credit risk models to support operation, reporting and

compliance purposes. Previously, he was a senior manager of MRM at GE Capital,

and a senior analyst of MRM at Freddie Mac Internal Audit.

Mr. Tian holds a PhD in Econometrics from SUNY at Albany (NY, US) and a Master in

Statistics from Tsinghua University (China). Mr. Tian has deep experience in

modeling, model risk management and regulatory communication.

Mr. Sasha Stoikov

Mr. Stoikov is OmniMarkets’ Quantitative Finance Advisor. He is currently the Head

of Research at Cornell Financial Engineering Manhattan (CFEM, New York, US), a

satellite campus of Cornell University. Previously, he was a Senior Vice President of

High Frequency Trading at Cantor Fitzgerald (New York, US).

Mr. Stoikov holds a PhD in Mathematics from The University of Texas at Austin, and

a BS in Mathematics from Massachusetts Institute of Technology (MIT). His

expertise includes order book dynamics, high frequency trading, quantitative

finance, applied mathematics, mathematical and statistical modeling.