Inside a Fund Valuation System: Database Architecture, Valuation Rule Engine, Batch Processing and Exception Handling

#

Every day, investors see a simple number:

NAV:

1.3526

But behind this number is not a simple formula.

A large asset management company’s valuation system may process:

• Tens of thousands of securities
• Hundreds of thousands of positions
• Millions of market data records
• Thousands of valuation rules
• Multiple accounting interfaces

The final output:

Net Asset Value (NAV)

is the result of a complete financial computing pipeline.

The process is very similar to a bank’s end-of-day batch processing system.

1. Where Does the Valuation System Sit in the Architecture?

#

A typical institutional fund technology architecture:

                 Market Data Platform

                         |
                         ↓

Trading System ----→ Portfolio Management System

                         |
                         ↓

                  Valuation System

              +----------+-----------+

              ↓                      ↓

       Fund Accounting          Risk System


              ↓

        Custodian Bank


              ↓

             TA System


              ↓

          Investors

The valuation system sits between:

Trading Facts

        ↓

Financial Value

2. A Valuation System Is Not Just a Database

#

Many people think fund valuation is simply:

Position × Market Price

That is only the simplest case.

A real valuation platform combines:

Asset Object

+

Market Data

+

Valuation Model

+

Accounting Rules

+

Regulatory Rules

Example:

Equity Valuation

#

Simple:

Shares Held

×

Closing Price

Bond Valuation

#

Much more complicated:

Face Value

+

Coupon

+

Accrued Interest

+

Remaining Duration

+

Yield Curve

+

Credit Adjustment

Alternative Assets

#

May require:

Cash Flow Forecast

+

Discount Model

+

Risk Adjustment

3. Core Database Design of a Valuation System

#

Large institutions usually do not store everything in one table.

A typical design contains several core data models.

3.1 Product Master Table

#

Example:

PRODUCT_INFO

Stores fund information:

Example:

000001

China Growth Fund

3.2 Security Master Database

#

This is one of the most important tables.

Example:

SECURITY_MASTER

Stores:

Security Code

Security Name

Market

Asset Type

Currency

Valuation Category

Example:

600519

Kweichow Moutai

Shanghai Stock Exchange

Equity

Why Is Security Master Important?

#

Different systems may use different identifiers.

Trading system:

600519.SH

Market data system:

600519

Custodian system:

CN600519

The valuation platform must normalize all identifiers.

3.3 Position Database

#

Core table:

POSITION_DETAIL

Records:

Fund ID

Security ID

Quantity

Cost

Holding Date

Example:

Fund A

Holding:

100,000 shares of Stock X

Cost:

1,400 RMB

3.4 Market Price Database

#

Example:

MARKET_PRICE

Stores:

Security

Date

Price

Source

Example:

600519

2026-09-01

1500 RMB

Exchange Closing Price

3.5 Valuation Result Table

#

Output table:

VALUATION_RESULT

Contains:

Fund

Security

Quantity

Unit Price

Market Value

Example:

Fund A

Stock X

100,000 shares

1500 RMB

150 million RMB

4. The Valuation Rule Engine: The Real Brain

#

Large fund valuation systems do not hard-code every calculation.

They use configurable rules.

Example:

Equity Rule

#

IF

Security_Type = STOCK


THEN

Use Closing Price

Bond Rule

#

IF

Security_Type = BOND


THEN

Use ChinaBond Valuation

Suspended Stock Rule

#

IF

Suspension = YES


THEN

Use Alternative Pricing Model

The system usually contains:

RULE_MASTER

RULE_DETAIL

RULE_PARAMETER

5. Why Must Valuation Rules Be Configurable?

#

Because regulations constantly change.

Example:

Old method:

Suspended Stock

=

Last Trading Price

New method:

Suspended Stock

=

Index Adjustment Method

If rules are hard-coded:

The company needs:

Development

↓

Testing

↓

Production Deployment

every time.

With a rule engine:

Only configuration changes are required.

6. End-of-Day Batch Processing Architecture

#

Fund valuation is usually not real-time.

It relies on:

Batch Processing

Daily timeline:

Market closes:

15:00

Then:

17:00

Start NAV Batch Jobs

Typical jobs:

JOB001

Import Market Data


JOB002

Synchronize Positions


JOB003

Calculate Asset Valuation


JOB004

Calculate Investment Income


JOB005

Accrue Fees


JOB006

Calculate NAV


JOB007

Send Data to Custodian

7. Batch Scheduler Architecture

#

Large institutions usually use job schedulers.

Workflow:

Job A Finished

        ↓

Start Job B

        ↓

Start Job C

This forms a dependency graph.

Example:

Market Data Complete

        ↓

Position Complete

        ↓

Valuation Complete

        ↓

Accounting Complete

        ↓

NAV Complete

8. How Does the System Handle Hundreds of Thousands of Assets?

#

The key technologies:

Partitioning

#

Example:

Batch 1

Equities


Batch 2

Bonds


Batch 3

Funds


Batch 4

Alternative Assets

Parallel Processing

#

Architecture:

              Master

                |

   +------------+------------+

   ↓            ↓            ↓

Worker 1    Worker 2    Worker 3

Similar to:

Large-scale transaction processing clusters.

9. Valuation Exception Handling

#

Production systems generate exceptions every day.

Case 1: Missing Price

#

Example:

Fund holds:

Stock A

Market data:

No Closing Price

System:

Exception Queue

Then:

Manual review.

Case 2: Position Mismatch

#

Fund company:

1 million shares

Custodian:

990,000 shares

Result:

NAV Publishing Blocked

Case 3: Abnormal NAV Movement

#

Yesterday:

1.0000

Today:

1.5000

Change:

+50%

System triggers:

NAV Exception Check

10. Why Do Fund Companies Need Manual Operations at Night?

#

Many valuation decisions cannot be fully automated.

Example:

A machine can detect:

No market price available

But it cannot always determine:

• Why the price is missing
• Which valuation model should apply
• Whether a special adjustment is required

Therefore:

Human experts are still involved:

• Portfolio managers
• Valuation committee
• Risk teams
• Accounting teams

11. Valuation System and Custodian Interface

#

Typical architecture:

Fund Valuation System

        |

        ↓

Interface Layer

        |

        ↓

Custodian Bank System

Data exchanged:

Position Files

Valuation Results

Asset Reports

NAV Files

Formats:

XML

CSV

Fixed-Length Files

Database Interface

12. Why Do Large Fund Companies Build Their Own Valuation Platforms?

#

Because different asset managers have different requirements.

Mutual Funds

#

Mostly standardized:

Listed Securities

+

Standard Rules

Private Funds

#

Need flexibility:

Customized Assets

+

Special Models

Insurance Asset Management

#

Focus:

Long-Term Assets

+

Liability Matching

Bank Wealth Management

#

Requires:

Bonds

+

Loans

+

Non-standard Assets

Therefore large institutions often build:

Core Valuation Platform

+

Business Rule Plugins

+

External Interfaces

13. Valuation System vs Trading System

#

They have completely different goals.

Trading System

#

Goal:

Speed

Focus:

Milliseconds

High TPS

Valuation System

#

Goal:

Accuracy

Focus:

Financial Consistency

Accounting Correctness

Trading cares about:

How fast can we execute?

Valuation cares about:

Is the value correct?

14. A Complete Nightly Production Flow

#

A real production timeline:

15:00

Market Closed


↓

15:30

Market Data Received


↓

16:30

Positions Frozen


↓

18:00

Valuation Batch Starts


↓

20:00

Accounting Generated


↓

22:00

Custodian Review


↓

23:00

Exception Handling


↓

24:00

NAV Published

Conclusion: NAV Is a Financial Data Factory

#

Investors only see:

1.3526

But behind this number:

Trading System

↓

Portfolio System

↓

Security Master

↓

Market Data System

↓

Valuation Rule Engine

↓

Valuation Database

↓

Fund Accounting

↓

Custodian Review

↓

TA System

↓

Investor Application

A fund NAV is not just a number.

It is the output of a highly coordinated:

financial data production pipeline

that runs every trading day.