mxm-refdata 0.3.0__tar.gz → 0.4.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- mxm_refdata-0.4.0/PKG-INFO +347 -0
- mxm_refdata-0.4.0/README.md +321 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/pyproject.toml +1 -1
- mxm_refdata-0.4.0/src/mxm/refdata/__init__.py +7 -0
- mxm_refdata-0.3.0/src/mxm/refdata/api/ref_data_api.py → mxm_refdata-0.4.0/src/mxm/refdata/api.py +43 -29
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/cli.py +129 -16
- mxm_refdata-0.4.0/src/mxm/refdata/config.py +86 -0
- mxm_refdata-0.4.0/src/mxm/refdata/database/sql_session_manager.py +168 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/services/bootstrap.py +28 -33
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/services/futures_contract_factory.py +13 -17
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/services/futures_product_factory.py +15 -17
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/services/ref_data_service.py +90 -40
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/services/smokecheck.py +2 -5
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/trading_calendars/trading_calendar.py +50 -14
- mxm_refdata-0.3.0/PKG-INFO +0 -228
- mxm_refdata-0.3.0/README.md +0 -202
- mxm_refdata-0.3.0/src/mxm/refdata/__init__.py +0 -1
- mxm_refdata-0.3.0/src/mxm/refdata/api/__init__.py +0 -1
- mxm_refdata-0.3.0/src/mxm/refdata/database/sql_session_manager.py +0 -135
- mxm_refdata-0.3.0/src/mxm/refdata/scripts/__init__.py +0 -1
- mxm_refdata-0.3.0/src/mxm/refdata/scripts/db_utils.py +0 -61
- mxm_refdata-0.3.0/src/mxm/refdata/scripts/manage_static_ref_data.py +0 -73
- mxm_refdata-0.3.0/src/mxm/refdata/utils/config.py +0 -32
- mxm_refdata-0.3.0/src/mxm/refdata/utils/resources.py +0 -29
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/LICENSE +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/data/first_day_of_interest_rule.json +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/data/futures_products.csv +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/data/last_trading_rule.json +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/database/__init__.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/mappings/__init__.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/mappings/futures_contract_vs_orm.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/mappings/futures_product_vs_orm.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/mappings/period_cycles_vs_orm.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/mappings/period_vs_orm.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/__init__.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/contracts/__init__.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/contracts/futures_contract.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/currencies.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/months.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/orm/__init__.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/orm/base.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/orm/futures_contracts.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/orm/futures_products.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/orm/period_cycles.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/orm/periods.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/period_cycles.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/periods.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/products/__init__.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/products/futures_product.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/products/settlement.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/reference_events.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/units.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/models/weekdays.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/parsing/__init__.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/parsing/futures_products_from_csv.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/py.typed +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/services/__init__.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/services/period_factory.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/trading_calendars/__init__.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/trading_calendars/first_day_of_interest.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/trading_calendars/last_trading_day.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/trading_calendars/nth_business_day.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/trading_calendars/nth_calendar_day_of_period.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/trading_calendars/nth_weekday_of_period.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/utils/__init__.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/utils/cache_manager.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/utils/period_types_codec.py +0 -0
- {mxm_refdata-0.3.0 → mxm_refdata-0.4.0}/src/mxm/refdata/utils/regex_patterns.py +0 -0
|
@@ -0,0 +1,347 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: mxm-refdata
|
|
3
|
+
Version: 0.4.0
|
|
4
|
+
Summary: Canonical reference data for Money Ex Machina.
|
|
5
|
+
License: MIT
|
|
6
|
+
License-File: LICENSE
|
|
7
|
+
Author: mxm
|
|
8
|
+
Author-email: contact@moneyexmachina.com
|
|
9
|
+
Requires-Python: >=3.13,<4.0
|
|
10
|
+
Classifier: License :: OSI Approved :: MIT License
|
|
11
|
+
Classifier: Programming Language :: Python :: 3
|
|
12
|
+
Classifier: Programming Language :: Python :: 3.13
|
|
13
|
+
Classifier: Programming Language :: Python :: 3.14
|
|
14
|
+
Requires-Dist: cachetools (>=7.1.1,<8.0.0)
|
|
15
|
+
Requires-Dist: exchange-calendars (>=4.11.1,<5.0.0)
|
|
16
|
+
Requires-Dist: pandas (>=2.3.3,<3.0.0)
|
|
17
|
+
Requires-Dist: pydantic-settings (>=2.14.1,<3.0.0)
|
|
18
|
+
Requires-Dist: rich (>=15.0.0,<16.0.0)
|
|
19
|
+
Requires-Dist: sqlalchemy (>=2.0.43,<3.0.0)
|
|
20
|
+
Requires-Dist: typer (>=0.25.1,<0.26.0)
|
|
21
|
+
Project-URL: Homepage, https://github.com/moneyexmachina/mxm-refdata
|
|
22
|
+
Project-URL: Issues, https://github.com/moneyexmachina/mxm-refdata/issues
|
|
23
|
+
Project-URL: Repository, https://github.com/moneyexmachina/mxm-refdata
|
|
24
|
+
Description-Content-Type: text/markdown
|
|
25
|
+
|
|
26
|
+
# mxm-refdata
|
|
27
|
+
|
|
28
|
+

|
|
29
|
+

|
|
30
|
+

|
|
31
|
+
[](https://microsoft.github.io/pyright/)
|
|
32
|
+
|
|
33
|
+
Reference-data ontology and contract-generation framework for the Money Ex Machina (MXM) ecosystem.
|
|
34
|
+
|
|
35
|
+
`mxm-refdata` provides deterministic definitions of futures products, futures contracts, periods, lifecycle dates, and trading-calendar relationships. It materialises these definitions into a queryable reference-data store and exposes them through a typed Python API.
|
|
36
|
+
|
|
37
|
+
The package is intended to answer questions such as:
|
|
38
|
+
|
|
39
|
+
```text
|
|
40
|
+
What futures products exist?
|
|
41
|
+
|
|
42
|
+
What contracts should exist for a given product?
|
|
43
|
+
|
|
44
|
+
When does a contract become active?
|
|
45
|
+
|
|
46
|
+
When is the last trading day?
|
|
47
|
+
|
|
48
|
+
Which contract is active on a given date?
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
without depending on any market-data vendor.
|
|
52
|
+
|
|
53
|
+
## Purpose
|
|
54
|
+
|
|
55
|
+
`mxm-refdata` defines financial reference objects and the rules by which they are constructed.
|
|
56
|
+
|
|
57
|
+
For example:
|
|
58
|
+
|
|
59
|
+
```text
|
|
60
|
+
cme_gbp_futures.Mar-2032
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
is not stored as a static object.
|
|
64
|
+
|
|
65
|
+
Instead it is deterministically derived from:
|
|
66
|
+
|
|
67
|
+
- a product specification,
|
|
68
|
+
- listing rules,
|
|
69
|
+
- period definitions,
|
|
70
|
+
- period-cycle membership,
|
|
71
|
+
- trading-calendar semantics,
|
|
72
|
+
- and lifecycle rules.
|
|
73
|
+
|
|
74
|
+
This allows downstream systems to reason about contracts independently of any particular data vendor.
|
|
75
|
+
|
|
76
|
+
Observed prices, quotes, trades, and exchange events belong to separate packages such as `mxm-marketdata`.
|
|
77
|
+
|
|
78
|
+
## Architecture
|
|
79
|
+
|
|
80
|
+
`mxm-refdata` consists of four conceptual layers.
|
|
81
|
+
|
|
82
|
+
### Product specifications
|
|
83
|
+
|
|
84
|
+
Human-authored definitions describing:
|
|
85
|
+
|
|
86
|
+
- products,
|
|
87
|
+
- contract sizes,
|
|
88
|
+
- listing rules,
|
|
89
|
+
- lifecycle rules,
|
|
90
|
+
- trading calendars,
|
|
91
|
+
- and valid period structures.
|
|
92
|
+
|
|
93
|
+
Currently these specifications are sourced from bundled CSV files.
|
|
94
|
+
|
|
95
|
+
Future versions are expected to source them from a dedicated `mxm-refdata-source` repository.
|
|
96
|
+
|
|
97
|
+
### Deterministic generation
|
|
98
|
+
|
|
99
|
+
Generation services construct:
|
|
100
|
+
|
|
101
|
+
- periods,
|
|
102
|
+
- period cycles,
|
|
103
|
+
- futures products,
|
|
104
|
+
- futures contracts,
|
|
105
|
+
- first day of interest,
|
|
106
|
+
- and last trading day.
|
|
107
|
+
|
|
108
|
+
### Materialised reference store
|
|
109
|
+
|
|
110
|
+
Generated entities are persisted into a reference-data database.
|
|
111
|
+
|
|
112
|
+
Current implementation:
|
|
113
|
+
|
|
114
|
+
```text
|
|
115
|
+
SQLite
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
Future deployments may use PostgreSQL through the same service layer.
|
|
119
|
+
|
|
120
|
+
### Query API
|
|
121
|
+
|
|
122
|
+
The materialised reference universe is exposed through:
|
|
123
|
+
|
|
124
|
+
- `RefDataAPI`
|
|
125
|
+
- operational CLI commands
|
|
126
|
+
- downstream MXM services
|
|
127
|
+
|
|
128
|
+
## Design Principles
|
|
129
|
+
|
|
130
|
+
### Explicit construction
|
|
131
|
+
|
|
132
|
+
`mxm-refdata` no longer discovers configuration implicitly.
|
|
133
|
+
|
|
134
|
+
Services are constructed from fully resolved configuration data.
|
|
135
|
+
|
|
136
|
+
```python
|
|
137
|
+
config = normalise_refdata_config_data(...)
|
|
138
|
+
api = RefDataAPI.from_config_data(config)
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
rather than:
|
|
142
|
+
|
|
143
|
+
```python
|
|
144
|
+
api = RefDataAPI()
|
|
145
|
+
```
|
|
146
|
+
|
|
147
|
+
### Derived state
|
|
148
|
+
|
|
149
|
+
The reference database is deterministic derived state.
|
|
150
|
+
|
|
151
|
+
Given:
|
|
152
|
+
|
|
153
|
+
- product specifications,
|
|
154
|
+
- lifecycle rules,
|
|
155
|
+
- trading-calendar semantics,
|
|
156
|
+
- and a contract materialisation horizon,
|
|
157
|
+
|
|
158
|
+
the database can be recreated from scratch.
|
|
159
|
+
|
|
160
|
+
### Separation of concerns
|
|
161
|
+
|
|
162
|
+
The package distinguishes between:
|
|
163
|
+
|
|
164
|
+
```text
|
|
165
|
+
Product definitions
|
|
166
|
+
Contract generation
|
|
167
|
+
Trading-calendar access
|
|
168
|
+
Reference-data storage
|
|
169
|
+
Query APIs
|
|
170
|
+
```
|
|
171
|
+
|
|
172
|
+
while exposing a unified operational interface.
|
|
173
|
+
|
|
174
|
+
## Installation
|
|
175
|
+
|
|
176
|
+
```bash
|
|
177
|
+
git clone https://github.com/moneyexmachina/mxm-refdata.git
|
|
178
|
+
cd mxm-refdata
|
|
179
|
+
poetry install
|
|
180
|
+
```
|
|
181
|
+
|
|
182
|
+
## CLI Usage
|
|
183
|
+
|
|
184
|
+
The CLI is intentionally explicit.
|
|
185
|
+
|
|
186
|
+
Create a reference database:
|
|
187
|
+
|
|
188
|
+
```bash
|
|
189
|
+
mxm-refdata rebuild \
|
|
190
|
+
--db-url sqlite:////tmp/mxm-refdata.db \
|
|
191
|
+
--contract-start-date 2024-01-01 \
|
|
192
|
+
--contract-end-date 2026-12-31
|
|
193
|
+
```
|
|
194
|
+
|
|
195
|
+
List products:
|
|
196
|
+
|
|
197
|
+
```bash
|
|
198
|
+
mxm-refdata products \
|
|
199
|
+
--db-url sqlite:////tmp/mxm-refdata.db
|
|
200
|
+
```
|
|
201
|
+
|
|
202
|
+
Inspect contract coverage:
|
|
203
|
+
|
|
204
|
+
```bash
|
|
205
|
+
mxm-refdata coverage \
|
|
206
|
+
--db-url sqlite:////tmp/mxm-refdata.db
|
|
207
|
+
```
|
|
208
|
+
|
|
209
|
+
Run operational smoke checks:
|
|
210
|
+
|
|
211
|
+
```bash
|
|
212
|
+
mxm-refdata smokecheck \
|
|
213
|
+
--db-url sqlite:////tmp/mxm-refdata.db
|
|
214
|
+
```
|
|
215
|
+
|
|
216
|
+
Future MXM applications are expected to provide higher-level runtime configuration so that users can invoke commands without repeatedly specifying database locations.
|
|
217
|
+
|
|
218
|
+
## Python API
|
|
219
|
+
|
|
220
|
+
```python
|
|
221
|
+
from datetime import date
|
|
222
|
+
|
|
223
|
+
from mxm.refdata import RefDataAPI
|
|
224
|
+
|
|
225
|
+
api = RefDataAPI.from_config_data(
|
|
226
|
+
{
|
|
227
|
+
"SQL_DB_URL": "sqlite:////tmp/mxm-refdata.db",
|
|
228
|
+
}
|
|
229
|
+
)
|
|
230
|
+
|
|
231
|
+
products = api.get_all_products()
|
|
232
|
+
|
|
233
|
+
contracts = api.get_contracts_for_product(
|
|
234
|
+
"cme_gbp_futures",
|
|
235
|
+
)
|
|
236
|
+
|
|
237
|
+
active_contracts = api.get_active_contracts(
|
|
238
|
+
as_of_date=date(2026, 5, 1),
|
|
239
|
+
)
|
|
240
|
+
```
|
|
241
|
+
|
|
242
|
+
## Configuration
|
|
243
|
+
|
|
244
|
+
The primary configuration fields are:
|
|
245
|
+
|
|
246
|
+
```text
|
|
247
|
+
SQL_DB_URL
|
|
248
|
+
|
|
249
|
+
REFDATA_DB_MODE
|
|
250
|
+
|
|
251
|
+
REFDATA_CONTRACT_START_DATE
|
|
252
|
+
REFDATA_CONTRACT_END_DATE
|
|
253
|
+
```
|
|
254
|
+
|
|
255
|
+
### Buildable mode
|
|
256
|
+
|
|
257
|
+
In buildable mode:
|
|
258
|
+
|
|
259
|
+
```text
|
|
260
|
+
REFDATA_DB_MODE=buildable
|
|
261
|
+
```
|
|
262
|
+
|
|
263
|
+
the database is treated as deterministic derived state.
|
|
264
|
+
|
|
265
|
+
If the database is empty, `mxm-refdata` may automatically materialise the configured reference universe.
|
|
266
|
+
|
|
267
|
+
This mode is intended for:
|
|
268
|
+
|
|
269
|
+
- development,
|
|
270
|
+
- CI,
|
|
271
|
+
- local experimentation,
|
|
272
|
+
- and bootstrap workflows.
|
|
273
|
+
|
|
274
|
+
### Managed mode
|
|
275
|
+
|
|
276
|
+
In managed mode:
|
|
277
|
+
|
|
278
|
+
```text
|
|
279
|
+
REFDATA_DB_MODE=managed
|
|
280
|
+
```
|
|
281
|
+
|
|
282
|
+
automatic materialisation is disabled.
|
|
283
|
+
|
|
284
|
+
The reference database must be created and maintained explicitly.
|
|
285
|
+
|
|
286
|
+
This mode is intended for operational deployments.
|
|
287
|
+
|
|
288
|
+
## Development
|
|
289
|
+
|
|
290
|
+
Install dependencies:
|
|
291
|
+
|
|
292
|
+
```bash
|
|
293
|
+
poetry install
|
|
294
|
+
```
|
|
295
|
+
|
|
296
|
+
Run the full validation suite:
|
|
297
|
+
|
|
298
|
+
```bash
|
|
299
|
+
make check
|
|
300
|
+
```
|
|
301
|
+
|
|
302
|
+
Repository compliance:
|
|
303
|
+
|
|
304
|
+
```bash
|
|
305
|
+
mxm-foundry check .
|
|
306
|
+
```
|
|
307
|
+
|
|
308
|
+
## Documentation
|
|
309
|
+
|
|
310
|
+
```text
|
|
311
|
+
docs/design.md
|
|
312
|
+
```
|
|
313
|
+
|
|
314
|
+
## Roadmap
|
|
315
|
+
|
|
316
|
+
### v0
|
|
317
|
+
|
|
318
|
+
- Futures product definitions
|
|
319
|
+
- Deterministic futures contract generation
|
|
320
|
+
- Trading-calendar integration
|
|
321
|
+
- Period and period-cycle models
|
|
322
|
+
- Materialised reference-data store
|
|
323
|
+
- Typed Python API
|
|
324
|
+
- Operational CLI
|
|
325
|
+
- Smoke-check framework
|
|
326
|
+
|
|
327
|
+
### v1
|
|
328
|
+
|
|
329
|
+
- Expanded futures coverage
|
|
330
|
+
- Richer lifecycle-rule models
|
|
331
|
+
- Explicit calendar abstractions
|
|
332
|
+
- Stronger operational tooling
|
|
333
|
+
- Improved ontology documentation
|
|
334
|
+
|
|
335
|
+
### v2
|
|
336
|
+
|
|
337
|
+
- ETF support
|
|
338
|
+
- FX support
|
|
339
|
+
- Historical rule evolution
|
|
340
|
+
- Governance and reconciliation workflows
|
|
341
|
+
- Integration with future MXM calendar services
|
|
342
|
+
- Multi-venue reference-data management
|
|
343
|
+
|
|
344
|
+
## License
|
|
345
|
+
|
|
346
|
+
MIT License. See `LICENSE`.
|
|
347
|
+
|
|
@@ -0,0 +1,321 @@
|
|
|
1
|
+
# mxm-refdata
|
|
2
|
+
|
|
3
|
+

|
|
4
|
+

|
|
5
|
+

|
|
6
|
+
[](https://microsoft.github.io/pyright/)
|
|
7
|
+
|
|
8
|
+
Reference-data ontology and contract-generation framework for the Money Ex Machina (MXM) ecosystem.
|
|
9
|
+
|
|
10
|
+
`mxm-refdata` provides deterministic definitions of futures products, futures contracts, periods, lifecycle dates, and trading-calendar relationships. It materialises these definitions into a queryable reference-data store and exposes them through a typed Python API.
|
|
11
|
+
|
|
12
|
+
The package is intended to answer questions such as:
|
|
13
|
+
|
|
14
|
+
```text
|
|
15
|
+
What futures products exist?
|
|
16
|
+
|
|
17
|
+
What contracts should exist for a given product?
|
|
18
|
+
|
|
19
|
+
When does a contract become active?
|
|
20
|
+
|
|
21
|
+
When is the last trading day?
|
|
22
|
+
|
|
23
|
+
Which contract is active on a given date?
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
without depending on any market-data vendor.
|
|
27
|
+
|
|
28
|
+
## Purpose
|
|
29
|
+
|
|
30
|
+
`mxm-refdata` defines financial reference objects and the rules by which they are constructed.
|
|
31
|
+
|
|
32
|
+
For example:
|
|
33
|
+
|
|
34
|
+
```text
|
|
35
|
+
cme_gbp_futures.Mar-2032
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
is not stored as a static object.
|
|
39
|
+
|
|
40
|
+
Instead it is deterministically derived from:
|
|
41
|
+
|
|
42
|
+
- a product specification,
|
|
43
|
+
- listing rules,
|
|
44
|
+
- period definitions,
|
|
45
|
+
- period-cycle membership,
|
|
46
|
+
- trading-calendar semantics,
|
|
47
|
+
- and lifecycle rules.
|
|
48
|
+
|
|
49
|
+
This allows downstream systems to reason about contracts independently of any particular data vendor.
|
|
50
|
+
|
|
51
|
+
Observed prices, quotes, trades, and exchange events belong to separate packages such as `mxm-marketdata`.
|
|
52
|
+
|
|
53
|
+
## Architecture
|
|
54
|
+
|
|
55
|
+
`mxm-refdata` consists of four conceptual layers.
|
|
56
|
+
|
|
57
|
+
### Product specifications
|
|
58
|
+
|
|
59
|
+
Human-authored definitions describing:
|
|
60
|
+
|
|
61
|
+
- products,
|
|
62
|
+
- contract sizes,
|
|
63
|
+
- listing rules,
|
|
64
|
+
- lifecycle rules,
|
|
65
|
+
- trading calendars,
|
|
66
|
+
- and valid period structures.
|
|
67
|
+
|
|
68
|
+
Currently these specifications are sourced from bundled CSV files.
|
|
69
|
+
|
|
70
|
+
Future versions are expected to source them from a dedicated `mxm-refdata-source` repository.
|
|
71
|
+
|
|
72
|
+
### Deterministic generation
|
|
73
|
+
|
|
74
|
+
Generation services construct:
|
|
75
|
+
|
|
76
|
+
- periods,
|
|
77
|
+
- period cycles,
|
|
78
|
+
- futures products,
|
|
79
|
+
- futures contracts,
|
|
80
|
+
- first day of interest,
|
|
81
|
+
- and last trading day.
|
|
82
|
+
|
|
83
|
+
### Materialised reference store
|
|
84
|
+
|
|
85
|
+
Generated entities are persisted into a reference-data database.
|
|
86
|
+
|
|
87
|
+
Current implementation:
|
|
88
|
+
|
|
89
|
+
```text
|
|
90
|
+
SQLite
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
Future deployments may use PostgreSQL through the same service layer.
|
|
94
|
+
|
|
95
|
+
### Query API
|
|
96
|
+
|
|
97
|
+
The materialised reference universe is exposed through:
|
|
98
|
+
|
|
99
|
+
- `RefDataAPI`
|
|
100
|
+
- operational CLI commands
|
|
101
|
+
- downstream MXM services
|
|
102
|
+
|
|
103
|
+
## Design Principles
|
|
104
|
+
|
|
105
|
+
### Explicit construction
|
|
106
|
+
|
|
107
|
+
`mxm-refdata` no longer discovers configuration implicitly.
|
|
108
|
+
|
|
109
|
+
Services are constructed from fully resolved configuration data.
|
|
110
|
+
|
|
111
|
+
```python
|
|
112
|
+
config = normalise_refdata_config_data(...)
|
|
113
|
+
api = RefDataAPI.from_config_data(config)
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
rather than:
|
|
117
|
+
|
|
118
|
+
```python
|
|
119
|
+
api = RefDataAPI()
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
### Derived state
|
|
123
|
+
|
|
124
|
+
The reference database is deterministic derived state.
|
|
125
|
+
|
|
126
|
+
Given:
|
|
127
|
+
|
|
128
|
+
- product specifications,
|
|
129
|
+
- lifecycle rules,
|
|
130
|
+
- trading-calendar semantics,
|
|
131
|
+
- and a contract materialisation horizon,
|
|
132
|
+
|
|
133
|
+
the database can be recreated from scratch.
|
|
134
|
+
|
|
135
|
+
### Separation of concerns
|
|
136
|
+
|
|
137
|
+
The package distinguishes between:
|
|
138
|
+
|
|
139
|
+
```text
|
|
140
|
+
Product definitions
|
|
141
|
+
Contract generation
|
|
142
|
+
Trading-calendar access
|
|
143
|
+
Reference-data storage
|
|
144
|
+
Query APIs
|
|
145
|
+
```
|
|
146
|
+
|
|
147
|
+
while exposing a unified operational interface.
|
|
148
|
+
|
|
149
|
+
## Installation
|
|
150
|
+
|
|
151
|
+
```bash
|
|
152
|
+
git clone https://github.com/moneyexmachina/mxm-refdata.git
|
|
153
|
+
cd mxm-refdata
|
|
154
|
+
poetry install
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
## CLI Usage
|
|
158
|
+
|
|
159
|
+
The CLI is intentionally explicit.
|
|
160
|
+
|
|
161
|
+
Create a reference database:
|
|
162
|
+
|
|
163
|
+
```bash
|
|
164
|
+
mxm-refdata rebuild \
|
|
165
|
+
--db-url sqlite:////tmp/mxm-refdata.db \
|
|
166
|
+
--contract-start-date 2024-01-01 \
|
|
167
|
+
--contract-end-date 2026-12-31
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
List products:
|
|
171
|
+
|
|
172
|
+
```bash
|
|
173
|
+
mxm-refdata products \
|
|
174
|
+
--db-url sqlite:////tmp/mxm-refdata.db
|
|
175
|
+
```
|
|
176
|
+
|
|
177
|
+
Inspect contract coverage:
|
|
178
|
+
|
|
179
|
+
```bash
|
|
180
|
+
mxm-refdata coverage \
|
|
181
|
+
--db-url sqlite:////tmp/mxm-refdata.db
|
|
182
|
+
```
|
|
183
|
+
|
|
184
|
+
Run operational smoke checks:
|
|
185
|
+
|
|
186
|
+
```bash
|
|
187
|
+
mxm-refdata smokecheck \
|
|
188
|
+
--db-url sqlite:////tmp/mxm-refdata.db
|
|
189
|
+
```
|
|
190
|
+
|
|
191
|
+
Future MXM applications are expected to provide higher-level runtime configuration so that users can invoke commands without repeatedly specifying database locations.
|
|
192
|
+
|
|
193
|
+
## Python API
|
|
194
|
+
|
|
195
|
+
```python
|
|
196
|
+
from datetime import date
|
|
197
|
+
|
|
198
|
+
from mxm.refdata import RefDataAPI
|
|
199
|
+
|
|
200
|
+
api = RefDataAPI.from_config_data(
|
|
201
|
+
{
|
|
202
|
+
"SQL_DB_URL": "sqlite:////tmp/mxm-refdata.db",
|
|
203
|
+
}
|
|
204
|
+
)
|
|
205
|
+
|
|
206
|
+
products = api.get_all_products()
|
|
207
|
+
|
|
208
|
+
contracts = api.get_contracts_for_product(
|
|
209
|
+
"cme_gbp_futures",
|
|
210
|
+
)
|
|
211
|
+
|
|
212
|
+
active_contracts = api.get_active_contracts(
|
|
213
|
+
as_of_date=date(2026, 5, 1),
|
|
214
|
+
)
|
|
215
|
+
```
|
|
216
|
+
|
|
217
|
+
## Configuration
|
|
218
|
+
|
|
219
|
+
The primary configuration fields are:
|
|
220
|
+
|
|
221
|
+
```text
|
|
222
|
+
SQL_DB_URL
|
|
223
|
+
|
|
224
|
+
REFDATA_DB_MODE
|
|
225
|
+
|
|
226
|
+
REFDATA_CONTRACT_START_DATE
|
|
227
|
+
REFDATA_CONTRACT_END_DATE
|
|
228
|
+
```
|
|
229
|
+
|
|
230
|
+
### Buildable mode
|
|
231
|
+
|
|
232
|
+
In buildable mode:
|
|
233
|
+
|
|
234
|
+
```text
|
|
235
|
+
REFDATA_DB_MODE=buildable
|
|
236
|
+
```
|
|
237
|
+
|
|
238
|
+
the database is treated as deterministic derived state.
|
|
239
|
+
|
|
240
|
+
If the database is empty, `mxm-refdata` may automatically materialise the configured reference universe.
|
|
241
|
+
|
|
242
|
+
This mode is intended for:
|
|
243
|
+
|
|
244
|
+
- development,
|
|
245
|
+
- CI,
|
|
246
|
+
- local experimentation,
|
|
247
|
+
- and bootstrap workflows.
|
|
248
|
+
|
|
249
|
+
### Managed mode
|
|
250
|
+
|
|
251
|
+
In managed mode:
|
|
252
|
+
|
|
253
|
+
```text
|
|
254
|
+
REFDATA_DB_MODE=managed
|
|
255
|
+
```
|
|
256
|
+
|
|
257
|
+
automatic materialisation is disabled.
|
|
258
|
+
|
|
259
|
+
The reference database must be created and maintained explicitly.
|
|
260
|
+
|
|
261
|
+
This mode is intended for operational deployments.
|
|
262
|
+
|
|
263
|
+
## Development
|
|
264
|
+
|
|
265
|
+
Install dependencies:
|
|
266
|
+
|
|
267
|
+
```bash
|
|
268
|
+
poetry install
|
|
269
|
+
```
|
|
270
|
+
|
|
271
|
+
Run the full validation suite:
|
|
272
|
+
|
|
273
|
+
```bash
|
|
274
|
+
make check
|
|
275
|
+
```
|
|
276
|
+
|
|
277
|
+
Repository compliance:
|
|
278
|
+
|
|
279
|
+
```bash
|
|
280
|
+
mxm-foundry check .
|
|
281
|
+
```
|
|
282
|
+
|
|
283
|
+
## Documentation
|
|
284
|
+
|
|
285
|
+
```text
|
|
286
|
+
docs/design.md
|
|
287
|
+
```
|
|
288
|
+
|
|
289
|
+
## Roadmap
|
|
290
|
+
|
|
291
|
+
### v0
|
|
292
|
+
|
|
293
|
+
- Futures product definitions
|
|
294
|
+
- Deterministic futures contract generation
|
|
295
|
+
- Trading-calendar integration
|
|
296
|
+
- Period and period-cycle models
|
|
297
|
+
- Materialised reference-data store
|
|
298
|
+
- Typed Python API
|
|
299
|
+
- Operational CLI
|
|
300
|
+
- Smoke-check framework
|
|
301
|
+
|
|
302
|
+
### v1
|
|
303
|
+
|
|
304
|
+
- Expanded futures coverage
|
|
305
|
+
- Richer lifecycle-rule models
|
|
306
|
+
- Explicit calendar abstractions
|
|
307
|
+
- Stronger operational tooling
|
|
308
|
+
- Improved ontology documentation
|
|
309
|
+
|
|
310
|
+
### v2
|
|
311
|
+
|
|
312
|
+
- ETF support
|
|
313
|
+
- FX support
|
|
314
|
+
- Historical rule evolution
|
|
315
|
+
- Governance and reconciliation workflows
|
|
316
|
+
- Integration with future MXM calendar services
|
|
317
|
+
- Multi-venue reference-data management
|
|
318
|
+
|
|
319
|
+
## License
|
|
320
|
+
|
|
321
|
+
MIT License. See `LICENSE`.
|