Machine Learning Portfolio Simulating and Optimizing Apparatuses, Methods and Systems

PRIORITY CLAIM

0001Applicant hereby claims benefit to priority under 35 USC § 119 as a non-provisional conversion of: U.S. provisional patent application Ser. No. 63/055,876, filed Jul. 23, 2020, entitled “Machine Learning Portfolio Simulating and Optimizing Apparatuses, Methods and Systems”, (attorney docket no. Fidelity0663PV).

0002The entire contents of the aforementioned applications are herein expressly incorporated by reference.

OTHER APPLICATIONS

0003Applications of interest include: U.S. patent application Ser. No. 14/494,443, filed Sep. 23, 2014, entitled “Life Cycle Based Portfolio Construction Platform Apparatuses, Methods and Systems”, (attorney docket no. Fidelity-0148US); U.S. patent application Ser. No. 14/286,792, filed May 23, 2014, entitled “SEASONAL PORTFOLIO CONSTRUCTION PLATFORM APPARATUSES, METHODS AND SYSTEMS”, (attorney docket no. Fidelity-0002US2); U.S. patent application Ser. No. 14/032,140, filed Sep. 19, 2013, entitled “SECTOR-BASED PORTFOLIO CONSTRUCTION PLATFORM APPARATUSES, METHODS AND SYSTEMS”, (attorney docket no. FIDE-001/01US270718-2003), U.S. patent application Ser. No. 13/370,396, filed Feb. 10, 2012, entitled “MULTI-FACTOR RISK MODELING PLATFORM”, (attorney docket no. FidelityFR06US).

0004The entire contents of the aforementioned applications are herein expressly incorporated by reference.

0005This application for letters patent disclosure document describes inventive aspects that include various novel innovations (hereinafter “disclosure”) and contains material that is subject to copyright, mask work, and/or other intellectual property protection. The respective owners of such intellectual property have no objection to the facsimile reproduction of the disclosure by anyone as it appears in published Patent Office file/records, but otherwise reserve all rights.

FIELD

0006The present innovations generally address machine learning and database systems, and more particularly, include Machine Learning Portfolio Simulating and Optimizing Apparatuses, Methods and Systems.

0007However, in order to develop a reader's understanding of the innovations, disclosures have been compiled into a single description to illustrate and clarify how aspects of these innovations operate independently, interoperate as between individual innovations, and/or cooperate collectively. The application goes on to further describe the interrelations and synergies as between the various innovations; all of which is to further compliance with 35 U.S.C. § 112.

BACKGROUND

0008People own all types of assets, some of which are secured instruments to underlying assets. People have used exchanges to facilitate trading and selling of such assets. Computer information systems, such as NAICO-NET, Trade*Plus and E*Trade allowed owners to trade securities assets electronically.

BRIEF DESCRIPTION OF THE DRAWINGS

0009Appendices and/or drawings illustrating various, non-limiting, example, innovative aspects of the Machine Learning Portfolio Simulating and Optimizing Apparatuses, Methods and Systems (hereinafter “MLPO”) disclosure, include:

0010<figref idref="DRAWINGS">FIGS. 1A-B</figref> show a datagraph illustrating data flow(s) for the MLPO;

0011<figref idref="DRAWINGS">FIGS. 2A-B</figref> show a logic flow illustrating embodiments of a machine learning simulated scenario processing (MLSSP) component for the MLPO;

0012<figref idref="DRAWINGS">FIG. 3</figref> shows an architecture for the MLPO;

0013<figref idref="DRAWINGS">FIG. 4</figref> shows a logic flow illustrating embodiments of a machine learning simulated scenario processing (MLSSP) component for the MLPO;

0014<figref idref="DRAWINGS">FIG. 5</figref> show a logic flow illustrating embodiments of a decision tree ensembles training (DTET) component for the MLPO;

0015<figref idref="DRAWINGS">FIGS. 6A-D</figref> show implementation case(s) for the MLPO;

0016<figref idref="DRAWINGS">FIGS. 7A-C</figref> show a logic flow illustrating embodiments of an expected returns calculation (ERC) component for the MLPO;

0017<figref idref="DRAWINGS">FIG. 8</figref> shows a datagraph illustrating data flow(s) for the MLPO;

0018<figref idref="DRAWINGS">FIG. 9</figref> shows a logic flow illustrating embodiments of a portfolio constructing (PC) component for the MLPO;

0019<figref idref="DRAWINGS">FIG. 10</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0020<figref idref="DRAWINGS">FIG. 11</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0021<figref idref="DRAWINGS">FIG. 12</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0022<figref idref="DRAWINGS">FIG. 13</figref> shows a datagraph illustrating data flow(s) for the MLPO;

0023<figref idref="DRAWINGS">FIGS. 14A-B</figref> show a logic flow illustrating embodiments of a predefined scenario constructing (PSC) component for the MLPO;

0024<figref idref="DRAWINGS">FIG. 15</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0025<figref idref="DRAWINGS">FIG. 16</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0026<figref idref="DRAWINGS">FIG. 17</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0027<figref idref="DRAWINGS">FIG. 18</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0028<figref idref="DRAWINGS">FIG. 19</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0029<figref idref="DRAWINGS">FIG. 20</figref> shows a datagraph illustrating data flow(s) for the MLPO;

0030<figref idref="DRAWINGS">FIG. 21</figref> shows a logic flow illustrating embodiments of a scenario based portfolio returns visualizing (SPRV) component for the MLPO;

0031<figref idref="DRAWINGS">FIG. 22</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0032<figref idref="DRAWINGS">FIG. 23</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0033<figref idref="DRAWINGS">FIG. 24</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0034<figref idref="DRAWINGS">FIG. 25</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0035<figref idref="DRAWINGS">FIG. 26</figref> shows a datagraph illustrating data flow(s) for the MLPO;

0036<figref idref="DRAWINGS">FIG. 27</figref> shows a logic flow illustrating embodiments of a business cycle based portfolio returns visualizing (BPRV) component for the MLPO;

0037<figref idref="DRAWINGS">FIG. 28</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0038<figref idref="DRAWINGS">FIG. 29</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0039<figref idref="DRAWINGS">FIG. 30</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0040<figref idref="DRAWINGS">FIG. 31</figref> shows an architecture for the MLPO;

0041<figref idref="DRAWINGS">FIG. 32</figref> shows an architecture for the MLPO;

0042<figref idref="DRAWINGS">FIGS. 33A-B</figref> show an architecture for the MLPO;

0043<figref idref="DRAWINGS">FIG. 34</figref> shows a datagraph illustrating data flow(s) for the MLPO;

0044<figref idref="DRAWINGS">FIG. 35</figref> shows a logic flow illustrating embodiments of a portfolio returns visualizing (PRV) component for the MLPO;

0045<figref idref="DRAWINGS">FIG. 36</figref> shows a logic flow illustrating embodiments of an asset return metrics calculating (ARMC) component for the MLPO;

0046<figref idref="DRAWINGS">FIG. 37</figref> shows an architecture for the MLPO;

0047<figref idref="DRAWINGS">FIG. 38</figref> shows an architecture for the MLPO;

0048<figref idref="DRAWINGS">FIG. 39</figref> shows an architecture for the MLPO;

0049<figref idref="DRAWINGS">FIG. 40</figref> shows an architecture for the MLPO;

0050<figref idref="DRAWINGS">FIG. 41</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0051<figref idref="DRAWINGS">FIG. 42</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0052<figref idref="DRAWINGS">FIG. 43</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0053<figref idref="DRAWINGS">FIG. 44</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0054<figref idref="DRAWINGS">FIG. 45</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0055<figref idref="DRAWINGS">FIG. 46</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0056<figref idref="DRAWINGS">FIG. 47</figref> shows a screenshot illustrating user interface(s) of the MLPO;

0057<figref idref="DRAWINGS">FIG. 48</figref> shows an architecture for the MLPO;

0058<figref idref="DRAWINGS">FIG. 49</figref> shows an architecture for the MLPO (e.g., Mutual Fund/ETF Model Architecture);

0059<figref idref="DRAWINGS">FIG. 50</figref> shows an architecture for the MLPO (e.g., Mutual Fund/ETF Pseudo Code—Parallel Computing);

0060<figref idref="DRAWINGS">FIG. 51</figref> shows an architecture for the MLPO (e.g., Mutual Fund/ETF Database Tables);

0061<figref idref="DRAWINGS">FIG. 52</figref> shows an architecture for the MLPO (e.g., Mutual Fund/ETF Pseudo Code—Proprietary Feature Selection);

0062<figref idref="DRAWINGS">FIG. 53</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., Market Risk Factor Exposure);

0063<figref idref="DRAWINGS">FIG. 54</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., Simulated Return Distribution Conditional on Market Scenario);

0064<figref idref="DRAWINGS">FIG. 55</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., Simulated Return Distribution Conditional on Business Cycle);

0065<figref idref="DRAWINGS">FIG. 56</figref> shows an architecture for the MLPO (e.g., EQUITY RISK MODELING WORKFLOW);

0066<figref idref="DRAWINGS">FIG. 57</figref> shows an architecture for the MLPO (e.g., PROPRIETARY FEATURE SELECTION METHOD);

0067<figref idref="DRAWINGS">FIG. 58</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., PMRI RISK ANALYSIS SCREENSHOT);

0068<figref idref="DRAWINGS">FIG. 59</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., MRI RISK ANALYSIS RETURN DRIVER SCREENSHOT);

0069<figref idref="DRAWINGS">FIG. 60</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., PMRI RISK ANALYSIS BUSINESS CYCLE SCREENSHOT);

0070<figref idref="DRAWINGS">FIG. 61</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., PMRI RISK ANALYSIS RISING VIX SCENARIO SCREENSHOT);

0071<figref idref="DRAWINGS">FIG. 62</figref> shows an architecture for the MLPO (e.g., PARALLEL COMPUTING PSEUDOCODE);

0072<figref idref="DRAWINGS">FIG. 63</figref> shows an architecture for the MLPO (e.g., EQUITY RISK MODELING FEATURE ENGINEERING WORKFLOW);

0073<figref idref="DRAWINGS">FIG. 64</figref> shows an architecture for the MLPO (e.g., EQUITY IDIOSYNCRATIC RISK MODELING WORKFLOW);

0074<figref idref="DRAWINGS">FIG. 65</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., ΔVIX VS HISTORICAL UNPRECEDENTEDNESS);

0075<figref idref="DRAWINGS">FIG. 66</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., HISTORICAL VS VAE);

0076<figref idref="DRAWINGS">FIG. 67</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., HISTORICAL VS PANIC SIM);

0077<figref idref="DRAWINGS">FIG. 68</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., 3M VIX THRESHOLDS VS UNPRECEDENTEDNESS (MSE) 3D);

0078<figref idref="DRAWINGS">FIG. 69</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., 6M VIX THRESHOLDS VS UNPRECEDENTEDNESS (MSE) 3D);

0079<figref idref="DRAWINGS">FIG. 70</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., 1Y VIX THRESHOLDS VS UNPRECEDENTEDNESS (MSE) 3D);

0080<figref idref="DRAWINGS">FIG. 71</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., CVaR FRONTIER COMPARISON WITH DIVERSIFICATION OF 0.6(LEFT) AND DIVERSIFICATION OF 0.3(RIGHT));

0081<figref idref="DRAWINGS">FIG. 72</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., TAIL RISK OPTIMIZATION RUNNING TIME COMPARISON OF INTEGER PROGRAMMING AND NON-INTEGER PROGRAMMING);

0082<figref idref="DRAWINGS">FIG. 73</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., EFFICIENT FRONTIER COMPARISON WITH RISK TOLERANCE OF 7(LEFT) AND RISK TOLERANCE OF 3(RIGHT));

0083<figref idref="DRAWINGS">FIG. 74</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., EFFICIENT FRONTIER COMPARISON WITH DIVERSIFICATION OF 0.7(LEFT) AND RISK DIVERSIFICATION OF 0.3(RIGHT));

0084<figref idref="DRAWINGS">FIG. 75</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., EFFICIENT FRONTIER COMPARISON WITH VIX RANGE OF (−3500,5500)(LEFT) AND VIX RANGE OF (−1500,3000)(RIGHT));

0085<figref idref="DRAWINGS">FIG. 76</figref> shows an architecture for the MLPO (e.g., FACTOR EXPOSURE GENERATION PSEUDO CODE);

0086<figref idref="DRAWINGS">FIG. 77</figref> shows an architecture for the MLPO (e.g., ASSET SIMULATION GENERATION PSEUDO CODE);

0087<figref idref="DRAWINGS">FIG. 78</figref> shows an architecture for the MLPO (e.g., FACTOR EXPOSURE GENERATION CONCEPT DIAGRAM);

0088<figref idref="DRAWINGS">FIG. 79</figref> shows an architecture for the MLPO (e.g., ASSET SIMULATION GENERATION CONCEPT DIAGRAM);

0089<figref idref="DRAWINGS">FIG. 80</figref> shows an architecture for the MLPO (e.g., CONVEXITY ADJUSTMENT PSEUDO CODE (STEP 1));

0090<figref idref="DRAWINGS">FIG. 81</figref> shows an architecture for the MLPO (e.g., CONVEXITY ADJUSTMENT PSEUDO CODE (STEP 2));

0091<figref idref="DRAWINGS">FIG. 82</figref> shows an architecture for the MLPO (e.g., OPTIONALITY ADJUSTMENT PSEUDO CODE);

0092<figref idref="DRAWINGS">FIG. 83</figref> shows an architecture for the MLPO (e.g., REAL-TIME ASSET SIMULATION PSEUDO CODE);

0093<figref idref="DRAWINGS">FIG. 84</figref> shows an architecture for the MLPO (e.g., REAL-TIME ASSET SIMULATION CONCEPT DIAGRAM (ORACLE RDS ON CLOUD));

0094<figref idref="DRAWINGS">FIG. 85</figref> shows an architecture for the MLPO (e.g., MULTIPLE USER-DEFINED SCENARIOS PSEUDO CODE);

0095<figref idref="DRAWINGS">FIG. 86</figref> shows an architecture for the MLPO (e.g., MULTIPLE USER-DEFINED SCENARIOS CONCEPT DIAGRAM);

0096<figref idref="DRAWINGS">FIG. 87</figref> shows an architecture for the MLPO (e.g., ASSET SIMULATION ER DIAGRAM);

0097<figref idref="DRAWINGS">FIG. 88</figref> shows an architecture for the MLPO (e.g., BOND LADDER CONSTRUCTION FLOW);

0098<figref idref="DRAWINGS">FIG. 89</figref> shows an architecture for the MLPO (e.g., BOND LADDER CONSTRUCTION API INPUT SAMPLE);

0099<figref idref="DRAWINGS">FIG. 90</figref> shows an architecture for the MLPO (e.g., BOND LADDER CONSTRUCTION API OUTPUT SAMPLE);

0100<figref idref="DRAWINGS">FIG. 91</figref> shows an architecture for the MLPO (e.g., RISK ANALYSIS API INPUT SAMPLE);

0101<figref idref="DRAWINGS">FIG. 92</figref> shows an architecture for the MLPO (e.g., RISK ANALYSIS API OUTPUT SAMPLE);

0102<figref idref="DRAWINGS">FIG. 93</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., BOND LADDER CONSTRUCTION USER INPUT/SELECTION SCREEN);

0103<figref idref="DRAWINGS">FIG. 94</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., BOND LADDER CONSTRUCTION—SAMPLE CORPORATE LADDER);

0104<figref idref="DRAWINGS">FIG. 95</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., BOND LADDER CONSTRUCTION—SAMPLE MUNI LADDER);

0105<figref idref="DRAWINGS">FIG. 96</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., BOND LADDER CONSTRUCTION—MAXIMIZE YIELD METHOD/OPTION);

0106<figref idref="DRAWINGS">FIG. 97</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., BOND LADDER CONSTRUCTION—RISK SCORE ADJUSTED METHOD/OPTION);

0107<figref idref="DRAWINGS">FIG. 98</figref> shows a screenshot illustrating user interface(s) of the MLPO (e.g., MULTIPLE USER-DEFINED SCENARIOS—MARKET SENSITIVITY ANALYSIS);

0108<figref idref="DRAWINGS">FIG. 99</figref> shows a block diagram illustrating embodiments of a MLPO controller.

0109Generally, the leading number of each citation number within the drawings indicates the figure in which that citation number is introduced and/or detailed. As such, a detailed discussion of citation number <b>101</b> would be found and/or introduced in <figref idref="DRAWINGS">FIG. 1</figref>. Citation number <b>201</b> is introduced in <figref idref="DRAWINGS">FIG. 2</figref>, etc. Any citations and/or reference numbers are not necessarily sequences but rather just example orders that may be rearranged and other orders are contemplated. Citation number suffixes may indicate that an earlier introduced item has been re-referenced in the context of a later figure and may indicate the same item, evolved/modified version of the earlier introduced item, etc., e.g., server <b>199</b> of <figref idref="DRAWINGS">FIG. 1</figref> may be a similar server <b>299</b> of <figref idref="DRAWINGS">FIG. 2</figref> in the same and/or new context.

DETAILED DESCRIPTION

0110The Machine Learning Portfolio Simulating and Optimizing Apparatuses, Methods and Systems (hereinafter “MLPO”) transforms machine learning simulation request, decision tree ensembles training request, expected returns calculation request, portfolio construction request, predefined scenario construction request, portfolio returns visualization request inputs, via MLPO components (e.g., MLSSP, DTET, ERC, PC, PSC, SPRV, BPRV, PRV, ARMC, etc. components), into machine learning simulation response, decision tree ensembles training response, expected returns calculation response, portfolio construction response, predefined scenario construction response, portfolio returns visualization response outputs. The MLPO components, in various embodiments, implement advantageous features as set forth below.

INTRODUCTION

0111The MLPO provides unconventional features (e.g., executing tradeable transactions to create an optimized portfolio based on expected returns simulated using machine learning techniques, a SQL database calculation engine) that were never before available in machine learning and database systems.

0112Tail-events have rare historical occurrence. They are difficult to model and forecast. However, they can be an essential part of resilient decision processes. The MLPO demonstrates unique abilities to model variations in volatilities and dependency structures across factors and over different time periods; provides rich estimates of tail-event; enables conditional outcomes of tail-events; and uses advanced linear and non-linear optimization processes for superior decision support. The optimization results provide model recommended solutions, such as for portfolio construction.

0113The MLPO presents the latest innovations in two core capabilities of investment management: 1) simulation driven investment insights and decision support and 2) machine driven portfolio allocation guidance. It combines the latest machine learning methods with leading-edge cloud computing techniques. It enables differentiations across many business units: analytics and insights to power a commercial electronic bond trading platform, power tools for evaluating portfolio construction bias, smart Bond Ladder products, and/or the like.

0114In various embodiments, the MLPO may include one or more of the following features:

01151. Maximizes the usage of high frequency historical data <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0116">a. Machine learning processes to impute missing data (e.g., in order to preserve higher frequency time-series data with gaps, and maximize the utility of all available historical data)</li><li id="ul0002-0002" num="0117">b. Flexible periodicity with overlapping techniques</li></ul></li></ul>

01182. Combines a mixer of copulas, flexible marginal distributions, rejection sampling and parallel computing for a single simulation engine which <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0119">a. Models changes in correlations and volatilities for “fat tail” events (e.g., using massive parallel computing to concurrently perform simulation and/or conditional simulation and/or stress scenario generations over cloud computing infrastructure)</li><li id="ul0004-0002" num="0120">b. Generates insights on the conditional impact of diverse factors on tail-events and volatilities</li></ul></li></ul>

01213. Allows calibration to forward-looking signals

01224. Allows domain experts to incorporate their subjective views

01235. Simulates longer horizon, multi-period outcomes with path dependency (e.g., using massive parallel computing frameworks in path-dependent, multi-period simulation to capture joint seasonality and mean-reversion tendencies across factors)

01246. Preserves the cadence of historical cycles in forward-looking simulation paths

01257. Allows forward-looking factor views to drive optimization results

01268. Applies “simulation-data-driven” approach for tailed-constrained portfolio optimization (e.g., to recommend solutions allowing tail-risk, tradability controls, etc.). In one embodiment, applies linear relaxation to CVaR constraints and mixed integer linear programming for optimization problem solving. In another embodiment, applies stochastic optimizer with VaR or CVaR and integer constraints to solve a non-linear optimization problem.

0127In some embodiments, the MLPO may implement a database calculation engine for calculating simulation data. The database calculation engine may be a SQL-based solution that effectively utilizes different data reduction and parallel execution techniques to reduce the overall response time. Instead of using a dedicated high-performance platform (e.g., IBM Netezza Data Appliance) the database calculation engine may be used for simulation calculation providing a faster, streamlined, cost effective and scalable solution (e.g., using Oracle RDS on Cloud) that provides calculation results in substantially less amount of time. Further, the database calculation engine eliminates having to maintain a complex infrastructure and applications associated with using a dedicated high-performance platform, and having to pay for additional licensing and maintenance costs.

0128The database calculation engine solution is faster as data does not have to be transferred outside of the database with an innovative data reduction strategy that applies to simulation generation, less complex as the solution may run entirely on a database, scalable as the solution effectively utilizes vertical scalability offered by RDS on Cloud and more maintainable.

0129In some implementations, the database calculation engine may provide the following features: <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0130">A novel way of calculating simulation data using a SQL only solution.</li><li id="ul0006-0002" num="0131">Application of unique data reduction techniques applicable specifically to the way data is aggregated for simulation data.</li><li id="ul0006-0003" num="0132">Use of vertical scalability and concurrency offered by Oracle RDS on Cloud for faster execution.</li><li id="ul0006-0004" num="0133">Processing that happens at the database level, eliminating having to transfer data outside to external systems and maximizing processing of data using cloud computing.</li><li id="ul0006-0005" num="0134">Faster and more cost effective than using high-performance platforms.</li></ul></li></ul>

0135In some implementations, the database calculation engine may utilize various innovative data reduction, scaling and parallel computing techniques (e.g., techniques to use global temporary tables and sessions, data reduction techniques to drastically reduce the amount of data used for processing thus lowering processing time, and several other data parallelization techniques used for generating simulation data): <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0136">Use of Multiple Batches to achieve higher degree of parallelism (DOP)</li><li id="ul0008-0002" num="0137">Use of Global Temporary Tables (GTT) to be able to run batch in multiple sessions and limit temporary storage requirements</li><li id="ul0008-0003" num="0138">Use of Data Reduction techniques to limit full table scans for joins between Factor Exposure and Factor Simulation table</li><li id="ul0008-0004" num="0139">Use of Parallel Query to parallelize generation of Asset Simulation and Contribution to Value at Risk data</li><li id="ul0008-0005" num="0140">Use of Parallel DML to parallelize inserting data related to Asset Simulation and Contribution to Value at Risk</li><li id="ul0008-0006" num="0141">Use of DDL for faster execution of delete statements to speed up cleanup of global temporary tables</li></ul></li></ul>

MLPO

0142<figref idref="DRAWINGS">FIGS. 1A-B</figref> show a datagraph illustrating data flow(s) for the MLPO. In <figref idref="DRAWINGS">FIGS. 1A-B</figref>, an administrative client <b>102</b> (e.g., of an administrative user) may send a machine learning simulation request <b>121</b> to a MLPO server <b>106</b> to facilitate generating a set of simulated scenarios (e.g., a scenario may be a set of simulated market factor changes). For example, the administrative client may be a desktop, a laptop, a tablet, a smartphone, a smartwatch, and/or the like that is executing a client application. In one implementation, the machine learning simulation request may include data such as a request identifier, configuration settings, and/or the like. In one embodiment, the administrative client may provide the following example machine learning simulation request, substantially in the form of a (Secure) Hypertext Transfer Protocol (“HTTP(S)”) POST message including eXtensible Markup Language (“XML”) formatted data, as provided below:

0000<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="294pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /authrequest.php HTTP/1.1</entry></row><row><entry>Host: www.server.com</entry></row><row><entry>Content-Type: Application/XML</entry></row><row><entry>Content-Length: 667</entry></row><row><entry></entry></row><row><entry><auth_request></entry></row><row><entry> <timestamp>2020-12-31 23:59:59</timestamp></entry></row><row><entry> <user_accounts_details></entry></row><row><entry>  <user_account_credentials></entry></row><row><entry>   <user_name>JohnDaDoeDoeDoooe@gmail.com</user_name></entry></row><row><entry>   <password>abc123</password></entry></row><row><entry>   //OPTIONAL <cookie>cookieID</cookie></entry></row><row><entry>   //OPTIONAL <digital_cert_link>www.mydigitalcertificate.com/</entry></row><row><entry>JohnDoeDaDoeDoe@gmail.com/mycertifcate.dc</digital_cert_link></entry></row><row><entry>   //OPTIONAL <digital_certificate>_DATA_</digital_certificate></entry></row><row><entry>  </user_account_credentials></entry></row><row><entry> </user_accounts_details></entry></row><row><entry> <client_details> //iOS Client with App and Webkit</entry></row><row><entry>   //it should be noted that although several client details</entry></row><row><entry>   //sections are provided to show example variants of client</entry></row><row><entry>   //sources, further messages will include only onto save</entry></row><row><entry>   //space</entry></row><row><entry>  <client_IP>10.0.0.123</client_IP></entry></row><row><entry>  <user_agent_string>Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_1 like Mac OS X)</entry></row><row><entry>AppleWebKit/537.51.2(KHTML, like Gecko) Version/7.0 Mobile/11D201</entry></row><row><entry>Safari/9537.53</user_agent_string></entry></row><row><entry>  <client_product_type>iPhone6,1</client_product_type></entry></row><row><entry>  <client_serial_number>DNXXX1X1XXXX</client_serial_number></entry></row><row><entry>  <client_UDID>3XXXXXXXXXXXXXXXXXXXXXXXXD</client_UDID></entry></row><row><entry>  <client_OS>iOS</client_OS></entry></row><row><entry>  <client_OS_version>7.1.1</client_OS_version></entry></row><row><entry>  <client_app_type>app with webkit</client_app_type></entry></row><row><entry>  <app_installed_flag>true</app_installed_flag></entry></row><row><entry>  <app_name>MLPO.app</app_name></entry></row><row><entry>  <app_version>1.0 </app_version></entry></row><row><entry>  <app_webkit_name>Mobile Safari</client_webkit_name></entry></row><row><entry>  <client_version>537.51.2</client_version></entry></row><row><entry> </client_details></entry></row><row><entry> <client_details> //iOS Client with Webbrowser</entry></row><row><entry>  <client_IP>10.0.0.123</client_IP></entry></row><row><entry>  <user_agent_string>Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_1 like Mac OS X)</entry></row><row><entry>AppleWebKit/537.51.2 (KHTML, like Gecko) Version/7.0 Mobile/11D201</entry></row><row><entry>Safari/9537.53</user_agent_string></entry></row><row><entry>  <client_product_type>iPhone6,1</client_product_type></entry></row><row><entry>  <client_serial_number>DNXXX1X1XXXX</client_serial_number></entry></row><row><entry>  <client_UDID>3XXXXXXXXXXXXXXXXXXXXXXXXD</client_UDID></entry></row><row><entry>  <client_OS>iOS</client_OS></entry></row><row><entry>  <client_OS_version>7.1.1</client_OS_version></entry></row><row><entry>  <client_app_type>web browser</client_app_type></entry></row><row><entry>  <client_name>Mobile Safari</client_name></entry></row><row><entry>  <client_version>9537.53</client_version></entry></row><row><entry> </client_details></entry></row><row><entry> <client_details> //Android Client with Webbrowser</entry></row><row><entry>  <client_IP>10.0.0.123</client_IP></entry></row><row><entry>  <user_agent_string>Mozilla/5.0 (Linux; U; Android 4.0.4; en-us; Nexus S</entry></row><row><entry>Build/IMM76D) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile</entry></row><row><entry>Safari/534.30</user_agent_string></entry></row><row><entry>  <client_product_type>Nexus S</client_product_type></entry></row><row><entry>  <client_serial_number>YXXXXXXXXZ</client_serial_number></entry></row><row><entry>  <client_UDID>FXXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX</client_UDID></entry></row><row><entry>  <client_OS>Android</client_OS></entry></row><row><entry>  <client_OS_version>4.0.4</client_OS_version></entry></row><row><entry>  <client_app_type>web browser</client_app_type></entry></row><row><entry>  <client_name>Mobile Safari</client_name></entry></row><row><entry>  <client_version>534.30</client_version></entry></row><row><entry> </client_details></entry></row><row><entry> <client_details> //Mac Desktop with Webbrowser</entry></row><row><entry>  <client_IP>10.0.0.123</client_IP></entry></row><row><entry>  <user_agent_string>Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3)</entry></row><row><entry>AppleWebKit/537.75.14 (KHTML, like Gecko) Version/7.0.3</entry></row><row><entry>Safari/537.75.14</user_agent_string></entry></row><row><entry>  <client_product_type>MacPro5,1</client_product_type></entry></row><row><entry>  <client_serial_number>YXXXXXXXXZ</client_serial_number></entry></row><row><entry>  <client_UDID>FXXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX</client_UDID></entry></row><row><entry>  <client_OS>Mac OS X</client_OS></entry></row><row><entry>  <client_OS_version>10.9.3</client_OS_version></entry></row><row><entry>  <client_app_type>web browser</client_app_type></entry></row><row><entry>  <client_name>Mobile Safari</client_name></entry></row><row><entry>  <client_version>537.75.14</client_version></entry></row><row><entry> </client_details></entry></row><row><entry> <machine_learning_simulation_request></entry></row><row><entry>  <request_identifier>ID_request_1</request_identifier></entry></row><row><entry>  <configuration_settings></entry></row><row><entry>   <historical_data>last 30 years</historical_data></entry></row><row><entry>   <rolling_window_period_length>6 months</rolling_window_period_length></entry></row><row><entry>   <time_period_bucket_type>FIXED</time_period_bucket_type></entry></row><row><entry>   <time_period_bucket_length>6 months</time_period_bucket_length></entry></row><row><entry>   <market_factors></entry></row><row><entry>    ID_interest_rate_5Y, ID_oil_price, ID_credit_spread, ID_SP500</entry></row><row><entry>   </market_factors></entry></row><row><entry>   <distribution_type>Gaussian</distribution_type></entry></row><row><entry>   <machine_learning_structure_type></entry></row><row><entry>    deep learning neural network</entry></row><row><entry>   </machine_learning_structure_type></entry></row><row><entry>   <hyper_parameters_to_test></entry></row><row><entry>    <hyper_parameters_option></entry></row><row><entry>     <option_identifier>ID_option_1</option_identifier></entry></row><row><entry>     <encoder>3 layers, 100 perceptrons each</encoder></entry></row><row><entry>     <latent_space>50 variables</latent_space></entry></row><row><entry>     <decoder>3 layers, 100 perceptrons each</decoder></entry></row><row><entry>    </hyper_parameters_option></entry></row><row><entry>    <hyper_parameters_option></entry></row><row><entry>     <option_identifier>ID_option_2</option_identifier></entry></row><row><entry>     <encoder>4 layers, 80 perceptrons each</encoder></entry></row><row><entry>     <latent_space>60 variables</latent_space></entry></row><row><entry>     <decoder>4 layers, 80 perceptrons each</decoder></entry></row><row><entry>    </hyper_parameters_option></entry></row><row><entry>    ...</entry></row><row><entry>   </hyper_parameters_to_test></entry></row><row><entry>   <number_of_simulated_market_scenarios></entry></row><row><entry>    1000 scenarios per time period bucket</entry></row><row><entry>   </number_of_simulated_market_scenarios></entry></row><row><entry>  </configuration_settings></entry></row><row><entry> </machine_learning_simulation_request></entry></row><row><entry></auth_request></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0143A machine learning simulated scenario processing (MLSSP) component <b>123</b> may utilize data provided in the machine learning simulation request to train a machine learning structure and/or to generate a set of simulated scenarios. See <figref idref="DRAWINGS">FIGS. 2A-B</figref> and <figref idref="DRAWINGS">FIG. 4</figref> for additional details regarding the MLSSP component.

0144The MLPO server <b>106</b> may send a scenario results store request <b>125</b> to a repository <b>110</b> to facilitate storing the generated set of simulated scenarios (e.g., a simulation) in a database. In one implementation, the scenario results store request may include data such as a request identifier, a simulation identifier, simulated scenarios, and/or the like. In one embodiment, the MLPO server may provide the following example scenario results store request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /scenario_results_store_request.php HTTP/1.1</entry></row><row><entry>Host: www.server.com</entry></row><row><entry>Content-Type: Application/XML</entry></row><row><entry>Content-Length: 667</entry></row><row><entry></entry></row><row><entry><scenario_results_store_request></entry></row><row><entry> <request_identifier>ID_request_2</request_identifier></entry></row><row><entry> <simulation_identifier>ID_sim_1</simulation_identifier></entry></row><row><entry> <simulated_scenarios></entry></row><row><entry>  <scenario></entry></row><row><entry>   <scenario_identifier>ID_scenario_1</scenario_identifier></entry></row><row><entry>   <market_factor></entry></row><row><entry>    <market_factor_identifier>ID_interest_rate_5Y</entry></row><row><entry>    </market_factor_identifier></entry></row><row><entry>    <market_factor_change>25 basis points</market_factor_change></entry></row><row><entry>   </market_factor></entry></row><row><entry>   <market_factor></entry></row><row><entry>    <market_factor_identifier>ID_oil_price</entry></row><row><entry>    </market_factor_identifier></entry></row><row><entry>    <market_factor_change>$10</market_factor_change></entry></row><row><entry>   </market_factor></entry></row><row><entry>   ...</entry></row><row><entry>  </scenario></entry></row><row><entry>  <scenario></entry></row><row><entry>   <scenario_identifier>ID_scenario_2</scenario_identifier></entry></row><row><entry>   <market_factor></entry></row><row><entry>    <market_factor_identifier>ID_interest_rate_5Y</entry></row><row><entry>    </market_factor_identifier></entry></row><row><entry>    <market_factor_change>50basis points</market_factor_change></entry></row><row><entry>   </market_factor></entry></row><row><entry>   <market_factor></entry></row><row><entry>    <market_factor_identifier>ID_oil_price</entry></row><row><entry>    </market_factor_identifier></entry></row><row><entry>    <market_factor_change>$15</market_factor_change></entry></row><row><entry>   </market_factor></entry></row><row><entry>   ...</entry></row><row><entry>  </scenario></entry></row><row><entry>  _</entry></row><row><entry> </simulated_scenarios></entry></row><row><entry></scenario_results_store_request></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0145The repository <b>110</b> may send a scenario results store response <b>127</b> to the MLPO server <b>106</b> to confirm that the generated set of simulated scenarios was stored successfully. In one implementation, the scenario results store response may include data such as a response identifier, a status, and/or the like. In one embodiment, the repository may provide the following example scenario results store response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="center" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /scenario_results_store_response.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><scenario_results_store_response></entry></row><row><entry /><entry> <response_identifier>ID_response_2</response_identifier></entry></row><row><entry /><entry> <status>OK</status></entry></row><row><entry /><entry></scenario_results_store_response></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0146The MLPO server <b>106</b> may send a machine learning simulation response <b>129</b> to the administrative client <b>102</b> to inform the administrative user that a set of simulated scenarios was generated successfully. In one implementation, the machine learning simulation response may include data such as a response identifier, a status, and/or the like. In one embodiment, the MLPO server may provide the following example machine learning simulation response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="center" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /machine_learning_simulation_response.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><machine_learning_simulation_response></entry></row><row><entry /><entry> <response_identifier>ID_response_1</response_identifier></entry></row><row><entry /><entry> <status>OK</status></entry></row><row><entry /><entry></machine_learning_simulation_response></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0147The administrative client <b>102</b> may send a decision tree ensembles training request <b>131</b> to the MLPO server <b>106</b> to facilitate training decision tree ensembles for a universe of securities. For example, different decision tree ensembles may be trained for each security for different predictive capabilities (e.g., one decision tree ensemble may be trained to estimate conditional Beta for a security, and another decision tree ensemble may be trained to estimate conditional default for the security). In one implementation, the decision tree ensembles training request may include data such as a request identifier, a universe of securities, predictive capabilities configuration, training features configuration, and/or the like. In one embodiment, the administrative client may provide the following example decision tree ensembles training request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /decision_tree_ensembles_training_request.php HTTP/1.1</entry></row><row><entry>Host: www.server.com</entry></row><row><entry>Content-Type: Application/XML</entry></row><row><entry>Content-Length: 667</entry></row><row><entry></entry></row><row><entry><decision_tree_ensembles_training_request></entry></row><row><entry> <request_identifier>ID_request_3</request_identifier></entry></row><row><entry> <universe_of_securities>Securities in S&P 500</entry></row><row><entry> </universe_of_securities></entry></row><row><entry> <predictive_capabilities_configuration></entry></row><row><entry>  <predictive_capability></entry></row><row><entry>   <predictive_capability_type>Conditional Beta</entry></row><row><entry>   </predictive_capability_type></entry></row><row><entry>   <training_features></entry></row><row><entry>    <feature>ratio of cash to market value of total assets</feature> </entry></row><row><entry>    <feature>ratio of net income to total assets</feature> </entry></row><row><entry>    <feature>size measure</feature> </entry></row><row><entry>    <feature>sector dummy variable</feature> </entry></row><row><entry>    ...</entry></row><row><entry>   </training_features></entry></row><row><entry>  </predictive_capability></entry></row><row><entry>  <predictive_capability></entry></row><row><entry>   <predictive_capability_type>Conditional Default</entry></row><row><entry>   </predictive_capability_type></entry></row><row><entry>   <training_features></entry></row><row><entry>    <feature>ratio of cash to market value of total assets</feature> </entry></row><row><entry>    <feature>unemployment rate</feature> </entry></row><row><entry>    <feature>value of VIX index</feature> </entry></row><row><entry>    ...</entry></row><row><entry>   </training_features></entry></row><row><entry>  </predictive_capability></entry></row><row><entry> </predictive_capabilities_configuration></entry></row><row><entry></decision_tree_ensembles_training_request></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0148A decision tree ensembles training (DTET) component <b>133</b> may utilize data provided in the decision tree ensembles training request to train decision tree ensembles for the universe of securities. See <figref idref="DRAWINGS">FIG. 5</figref> for additional details regarding the DTET component.

0149The MLPO server <b>106</b> may send a decision tree ensembles store request <b>135</b> to the repository <b>110</b> to facilitate storing the trained decision tree ensembles. In one implementation, the decision tree ensembles store request may include data such as a request identifier, decision tree ensembles, and/or the like. In one embodiment, the MLPO server may provide the following example decision tree ensembles store request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00006" num="00006"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /decision_tree_ensembles_store_request.php HTTP/1.1</entry></row><row><entry>Host: www.server.com</entry></row><row><entry>Content-type: Application/XML</entry></row><row><entry>Content-Length: 667</entry></row><row><entry></entry></row><row><entry><decision_tree_ensemble_store_request></entry></row><row><entry> <request_indentifier>ID_request_4</request_identifier></entry></row><row><entry> <decision_tree_ensembles></entry></row><row><entry>  <decision_tree_ensemble></entry></row><row><entry>   <decision_tree_ensemble_id>ID_DTE_1</entry></row><row><entry>   </decision_tree_ensemble_id></entry></row><row><entry>   <associated_security>MSFT</associated_security></entry></row><row><entry>   <predictive_capability_type>Conditional Beta</entry></row><row><entry>   </predictive_capability_type></entry></row><row><entry>   <decision_tree_ensemble_data></entry></row><row><entry>    decision tree ensemble datastructure</entry></row><row><entry>   </decision_tree_ensemble_data></entry></row><row><entry>  </decision_tree_ensemble></entry></row><row><entry>  <decision_tree_ensemble></entry></row><row><entry>   <decision_tree_ensemble_id>ID_DTE_2</entry></row><row><entry>   </decision_tree_ensemble_id></entry></row><row><entry>   <associated_security>MSFT</associated_security></entry></row><row><entry>   <predictive_capability_type>Conditional Default</entry></row><row><entry>   </predictive_capability_type></entry></row><row><entry>   <decision_tree_ensemble_data></entry></row><row><entry>    decision tree ensemble datastructure</entry></row><row><entry>   </decision_tree_ensemble_data></entry></row><row><entry>  </decision_tree_ensemble></entry></row><row><entry>   <decision_tree_ensemble_id>ID_DTE_3</entry></row><row><entry>   </decision_tree_ensemble_id></entry></row><row><entry>   <associated_security>AAPL</associated_security></entry></row><row><entry>   <predictive_capability_type>Conditional Beta</entry></row><row><entry>   </predictive_capability_type></entry></row><row><entry>   <decision_tree_ensemble_data></entry></row><row><entry>    decision tree ensemble datastructure</entry></row><row><entry>   </decision_tree_ensemble_data></entry></row><row><entry>  </decision_tree_ensemble></entry></row><row><entry>  <decision_tree_ensemble></entry></row><row><entry>   <decision_tree_ensemble_id>ID_DTE_4</entry></row><row><entry>   </decision_tree_ensemble_id></entry></row><row><entry>   <associated_security>AAPL</associated_security></entry></row><row><entry>   <predictive_capability_type>Conditional Default</entry></row><row><entry>   </predictive_capability_type></entry></row><row><entry>   <decision_tree_ensemble_data></entry></row><row><entry>    decision tree ensemble datastructure</entry></row><row><entry>   </decision_tree_ensemble_data></entry></row><row><entry>  </decision_tree_ensemble></entry></row><row><entry>  ...</entry></row><row><entry> </decision_tree_ensembles></entry></row><row><entry></decision_tree_ensembles_store_request></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0150The repository <b>110</b> may send a decision tree ensembles store response <b>137</b> to the MLPO server <b>106</b> to confirm that the trained decision tree ensembles were stored successfully. In one implementation, the decision tree ensembles store response may include data such as a response identifier, a status, and/or the like. In one embodiment, the repository may provide the following example decision tree ensembles store response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00007" num="00007"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="center" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /decision_tree_ensembles_store_response.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><decision_tree_ensembles_store_response></entry></row><row><entry /><entry> <response_identifier>ID_response_4</response_identifier></entry></row><row><entry /><entry> <status>OK</status></entry></row><row><entry /><entry></decision_tree_ensembles_store_response></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0151The MLPO server <b>106</b> may send a decision tree ensembles training response <b>139</b> to the administrative client <b>102</b> to inform the administrative user that decision tree ensembles were trained successfully. In one implementation, the decision tree ensembles training response may include data such as a response identifier, a status, and/or the like. In one embodiment, the MLPO server may provide the following example decision tree ensembles training response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00008" num="00008"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="center" /><colspec colname="2" colwidth="203pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /decision_tree_ensembles_training_response.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><decision_tree_ensembles_training_response></entry></row><row><entry /><entry> <response_identifier>ID_response_3</response_identifier></entry></row><row><entry /><entry> <status>OK</status></entry></row><row><entry /><entry></decision_tree_ensembles_training_response></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0152The administrative client <b>102</b> may send an expected returns calculation request <b>141</b> to the MLPO server <b>106</b> to facilitate calculating expected returns for the universe of securities under the simulated scenarios. In one implementation, the expected returns calculation request may include data such as a request identifier, a universe of securities, a simulation identifier, a set of simulated scenarios, and/or the like. In one embodiment, the administrative client may provide the following example expected returns calculation request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00009" num="00009"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /expected_returns_calculation_request.php HTTP/1.1</entry></row><row><entry>Host: www.server.com</entry></row><row><entry>Content-Type: Application/XML</entry></row><row><entry>Content-Length: 667</entry></row><row><entry></entry></row><row><entry><expected_returns_calculation_request></entry></row><row><entry> <request_identifier>ID_request_5</request_identifier></entry></row><row><entry> <universe_of_securities>Securities in S&P 500</universe_of_securities></entry></row><row><entry> <simulation_identifier>ID_sim_1</simulation_identifier></entry></row><row><entry> <simulated_scenarios>ID_scenario_1, ID_scenario_2,</entry></row><row><entry> ...</simulated_scenarios></entry></row><row><entry></expected_returns_calculation_request></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0153The MLPO server <b>106</b> may send a scenario results retrieve request <b>145</b> to the repository <b>110</b> to facilitate retrieving simulated market factor changes for a simulated scenario. In one implementation, the scenario results retrieve request may include data such as a request identifier, a simulation identifier, a scenario identifier, and/or the like. In one embodiment, the MLPO server may provide the following example scenario results retrieve request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00010" num="00010"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="center" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /scenario_results_retrieve_request.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><scenario_results_retrieve_request></entry></row><row><entry /><entry> <request_identifier>ID_request_6</request_identifier></entry></row><row><entry /><entry> <simulation_identifier>ID_sim_1</simulation_identifier></entry></row><row><entry /><entry> <scenario_identifier>ID_scenario_1</scenario_identifier></entry></row><row><entry /><entry></scenario_results_retrieve_request></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0154The repository <b>110</b> may send a scenario results retrieve response <b>147</b> to the MLPO server <b>106</b> with the requested simulated market factor changes data. In one implementation, the scenario results retrieve response may include data such as a response identifier, the requested simulated market factor changes data, and/or the like. In one embodiment, the repository may provide the following example scenario results retrieve response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00011" num="00011"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /scenario_results_retrieve_response.php HTTP/1.1</entry></row><row><entry>Host: www.server.com</entry></row><row><entry>Content-Type: Application/XML</entry></row><row><entry>Content-Length: 667</entry></row><row><entry></entry></row><row><entry><scenario_results_retrieve_response></entry></row><row><entry> <response_identifier>ID_response_6</response_identifier></entry></row><row><entry> <scenario_data></entry></row><row><entry>  <market_factor></entry></row><row><entry>   <market_factor_identifier>ID_interest_rate_5Y</entry></row><row><entry>   </market_factor_identifier></entry></row><row><entry>   <market_factor_change>25 basis points</market_factor_change></entry></row><row><entry>  </market_factor></entry></row><row><entry>  <market_factor></entry></row><row><entry>   <market_factor_identifier>ID_oil_price</market_factor_identifier></entry></row><row><entry>   <market_factor_change>$10</market_factor_change></entry></row><row><entry>  </market_factor></entry></row><row><entry>  ...</entry></row><row><entry> </scenario_data></entry></row><row><entry></scenario_results_retrieve_response></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0155An expected returns calculation (ERC) component <b>149</b> may utilize data provided in the expected returns calculation request, data provided in the scenario results retrieve response, and/or the trained decision tree ensembles to calculate expected returns for the universe of securities under the simulated scenarios. See <figref idref="DRAWINGS">FIG. 7A</figref> for additional details regarding the ERC component.

0156The MLPO server <b>106</b> may send an expected returns store request <b>151</b> to the repository <b>110</b> to facilitate storing the calculated expected returns. In one implementation, the expected returns store request may include data such as a request identifier, expected returns, and/or the like. In one embodiment, the MLPO server may provide the following example expected returns store request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00012" num="00012"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="center" /><colspec colname="2" colwidth="203pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /expected_returns_store_request.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><expected_returns_store_request></entry></row><row><entry /><entry> <request_identifier>ID_request_7</request_identifier></entry></row><row><entry /><entry> <expected_returns></entry></row><row><entry /><entry>  <simulation_identifier>ID_sim_1</simulation_identifier></entry></row><row><entry /><entry>  <scenario></entry></row><row><entry /><entry>   <scenario_identifier>ID_scenario_1</scenario_identifier></entry></row><row><entry /><entry>   <security></entry></row><row><entry /><entry>    <security_identifier>MSFT</security_identifier></entry></row><row><entry /><entry>    <expected_return>10%</expected_return></entry></row><row><entry /><entry>   </security></entry></row><row><entry /><entry>   <security></entry></row><row><entry /><entry>    <security_identifier>AAPL</security_identifier></entry></row><row><entry /><entry>    <expected_return>12%</expected_return></entry></row><row><entry /><entry>   </security></entry></row><row><entry /><entry>   ...</entry></row><row><entry /><entry>  </scenario></entry></row><row><entry /><entry>  <scenario></entry></row><row><entry /><entry>   <scenario_identifier>ID_scenario_2</scenario_identifier></entry></row><row><entry /><entry>   <security></entry></row><row><entry /><entry>    <security_identifier>MSFT</security_identifier></entry></row><row><entry /><entry>    <expected_return>15%</expected_return></entry></row><row><entry /><entry>   </security></entry></row><row><entry /><entry>   <security></entry></row><row><entry /><entry>    <security_identifier>AAPL</security_identifier></entry></row><row><entry /><entry>    <expected_return>13%</expected_return></entry></row><row><entry /><entry>   </security></entry></row><row><entry /><entry>   ...</entry></row><row><entry /><entry>  </scenario></entry></row><row><entry /><entry>  ...</entry></row><row><entry /><entry> </expected_returns></entry></row><row><entry /><entry></expected_returns_store_request></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0157The repository <b>110</b> may send an expected returns store response <b>153</b> to the MLPO server <b>106</b> to confirm that the calculated expected returns were stored successfully. In one implementation, the expected returns store response may include data such as a response identifier, a status, and/or the like. In one embodiment, the repository may provide the following example expected returns store response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00013" num="00013"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="center" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /expected_returns_store_response.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><expected_returns_calculation_response></entry></row><row><entry /><entry> <response_identifier>ID_response_7</response_identifier></entry></row><row><entry /><entry> <status>OK</status></entry></row><row><entry /><entry></expected_returns_calculation_response></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0158The MLPO server <b>106</b> may send an expected returns calculation response <b>155</b> to the administrative client <b>102</b> to inform the administrative user that expected returns for the universe of securities under the simulated scenarios were calculated successfully. In one implementation, the expected returns calculation response may include data such as a response identifier, a status, and/or the like. In one embodiment, the MLPO server may provide the following example expected returns calculation response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00014" num="00014"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="center" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /expected_returns_calculation_response.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><expected_returns_calculation_response></entry></row><row><entry /><entry> <response_identifier>ID_response_5</response_identifier></entry></row><row><entry /><entry> <status>OK</status></entry></row><row><entry /><entry></expected_returns_calculation_response></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0159<figref idref="DRAWINGS">FIGS. 2A-B</figref> show a logic flow illustrating embodiments of a machine learning simulated scenario processing (MLSSP) component for the MLPO. In <figref idref="DRAWINGS">FIG. 2A</figref>, a machine learning simulated scenario processing request may be obtained at <b>201</b>. For example, the machine learning simulated scenario processing request may be obtained as a result of an administrative user requesting generation of a set of simulated scenarios.

0160A rolling window period length may be determined at <b>205</b>. In one embodiment, historical data may be analyzed to calculate changes to a set of market factors during each rolling window period of a specified rolling window period length. In one implementation, the machine learning simulated scenario processing request may be parsed (e.g., using PHP commands) to determine historical data to analyze (e.g., based on the value of the historical_data field) and/or the rolling window period length to use for analysis (e.g., based on the value of the rolling_window_period_length field). For example, the machine learning simulated scenario processing request may specify that the last 30 years of historical data should be analyzed using 6 month rolling window periods.

0161Market factors to process may be determined at <b>209</b>. For example, market factors may include interest rates, credit spread, oil price, equity indices, and/or the like, and changes to the market factors during a rolling window period jointly describe a market scenario (e.g., a historical market scenario for historical changes, a simulated market scenario for simulated changes). In one implementation, the machine learning simulated scenario processing request may be parsed (e.g., using PHP commands) to determine the market factors to process (e.g., based on the value of the market_factors field). In another implementation, a set of default market factors to process may be specified in a configuration setting.

0162A determination may be made at <b>213</b> whether there remain market factors to process. In one implementation, each of the market factors may be processed. If there remain market factors to process, the next market factor (e.g., 6 month change in interest rates) may be selected for processing at <b>217</b>.

0163A determination may be made at <b>221</b> whether there remain rolling window periods to analyze. In one implementation, historical data for the selected market factor may be analyzed during each of the rolling window periods. If there remain rolling window periods to analyze, the next rolling window period may be selected for analysis at <b>225</b>. For example, the next rolling window period may be two specific time points (e.g., days) 6 months apart.

0164A determination may be made at <b>229</b> whether data for the selected rolling window period is available. In one implementation, this determination may be made based on whether historical data for the selected market factor is available for both time points (e.g., for both days) of the selected rolling window period.

0165If historical market factor data is unavailable for one or both time points (e.g., days) of the selected rolling window period, the missing data may be imputed using a machine learning (e.g., k-Nearest Neighbors (k-NN)) method at <b>233</b> based on market factor data for other time points (e.g., for other days). In one implementation, the k-NN method may be used to match records (e.g., a record may be a set of market factors for a time point) with missing data points (e.g., a missing data point may be a missing market factor data for a time point) in a multi-dimensional space. For example, the missing data for the selected market factor for a time point may be calculated as the average of values of the selected market factor for k nearest neighbors of the time point as determined based on similarity of the other market factors.

0166Change to the selected market factor during the selected rolling window period may be calculated at <b>237</b>. In one implementation, the change to the selected market factor during the selected rolling window period may be calculated by determining the delta between values of the selected market factor at the two time points of the selected rolling window period. For example, the 6 month change in 5 year interest rates for the rolling window period between Jan. 7, 2019 and Jul. 8, 2019, may be calculated by subtracting the US Treasury 5 Year Par Yield on Jan. 7, 2019 from the US Treasury 5 Year Par Yield on Jul. 8, 2019. In another example, the 6 month change in 5 year interest rates for the rolling window period between Jan. 8, 2019 and Jul. 9, 2019, may be calculated by subtracting the US Treasury 5 Year Par Yield on Jan. 8, 2019 from the US Treasury 5 Year Par Yield on Jul. 9, 2019.

0167Once changes to each of the market factors during each of the rolling window periods are calculated, a determination may be made at <b>241</b> regarding the type of time period buckets to utilize. In one embodiment, fixed length time period buckets may be utilized. In another embodiment, variable length time period buckets may be utilized. In one implementation, the machine learning simulated scenario processing request may be parsed (e.g., using PHP commands) to determine the type of time period buckets to utilize (e.g., based on the value of the time_period_bucket_type field).

0168If fixed length time period buckets are utilized, the length of time period buckets to utilize may be determined at <b>245</b>. In one implementation, the machine learning simulated scenario processing request may be parsed (e.g., using PHP commands) to determine the length of time period buckets to utilize (e.g., based on the value of the time_period_bucket_length field). For example, the machine learning simulated scenario processing request may specify that historical market scenarios generated from the last 30 years of historical data (e.g., using calculated changes from <b>237</b>) should be split using 6 month long time period buckets, resulting in 60 time period buckets to process. It is to be understood that the length of time period buckets is independent of the rolling window period length (e.g., the two lengths may be the same or may be different).

0169If variable length time period buckets are utilized, time period buckets reflective of changes in volatilities and correlations of the historical data may be determined at <b>249</b>. In one implementation, the time period buckets may be selected by judging the overall goodness of fit between simulated data from the time period buckets and historical data. KS tests and Cramer test may be performed jointly between the simulated market scenarios and the historical market scenarios. The splitting into time period buckets may support the objective function of minimizing the KS test values of the marginal distributions and Cramer test value of the multivariate distribution of simulated market scenarios vs. realized historical market scenarios. For example, the machine learning simulated scenario processing request may specify that historical market scenarios generated from the last 30 years of historical data (e.g., using calculated changes from <b>237</b>) should be split by bucketing historical market scenarios from the same economic cycle (e.g., early cycle, mid cycle, late cycle, recession) together to summarize the changes in volatilities and correlation structure. In some implementations, the number of time period buckets may be determined by balancing the amount of historical data vs. the number of market factors. For example, given that data frequency is constant, as the number of market factors increases the time duration utilized for each time period bucket increases.

0170The historical market scenarios may be bucketed in accordance with the determined time period buckets at <b>253</b>. In one implementation, each historical market scenario may be assigned a bucket identifier that specifies the time period bucket associated with the respective historical market scenario.

0171A determination may be made at <b>257</b> whether there remain time period buckets to process. In one implementation, each of the time period buckets may be processed. If there remain time period buckets to process, the next time period bucket (e.g., historical market scenarios associated with the next 6 month long time period bucket) may be selected for processing at <b>261</b>.

0172A deep learning neural network for the selected time period bucket may be trained at <b>281</b>. For example, the deep learning neural network may be a Gaussian-Mixture Variational Autoencoder. In one embodiment, the deep learning neural network may be trained to map historical market factor changes to latent space variables and/or to map latent space variables to simulated market factor changes. See <figref idref="DRAWINGS">FIG. 2B</figref> for additional details regarding training the deep learning neural network. See <figref idref="DRAWINGS">FIG. 3</figref> for an exemplary deep learning neural network architecture.

0173The number of market scenarios to simulate may be determined at <b>289</b>. For example, 1,000 scenarios may be simulated (e.g., resulting in 60,000 total simulated scenarios over 60 time period buckets). In one implementation, the machine learning simulated scenario processing request may be parsed (e.g., using PHP commands) to determine the number of market scenarios to simulate for each of the time period buckets (e.g., based on the value of the number_of_simulated_market_scenarios field). In another implementation, the number of market scenarios to simulate for each of the time period buckets may be specified in a configuration setting. In another implementation, the number of market scenarios to simulate may differ for different time period buckets. For example, the number of market scenarios to simulate may be determined as an AI-driven weight learned by minimizing the L2 Norm between real data and simulated data.

0174A determination may be made at <b>293</b> whether there remain market scenarios to simulate. If so, simulated data may be generated using latent space variables at <b>295</b>. In one implementation, random values for latent space variables of the trained deep learning neural network may be generated. For example, a random value for a latent space variable of the trained deep learning neural network may be generated (e.g., by optimizing the number of perceptrons, the number of layers of the encoder and decoder neural networks, and/or the number of latent space variables with the objective function of minimizing the L2 Norm between generated market factor changes and historical market factor changes) from a Gaussian or Gaussian mixture distribution (e.g., from a multivariate Gaussian distribution) using the Python NumPy library (e.g., with three inputs including the number of samples to be generated, mean and variance from the encoder).

0175A set of simulated market factor changes may be generated from the simulated data using a neural network decoder of the trained deep learning neural network at <b>297</b>. In one implementation, the generated random values of latent space variables may be fed through the neural network decoder of the trained deep learning neural network to obtain a set of simulated market factor changes (e.g., the set of simulated market factor changes may be referred to as a simulated market scenario).

0176The simulated scenario may be stored in a database at <b>299</b>. In one implementation, the simulated scenario may be stored (e.g., in a batch with other simulated scenarios) via a scenario results store request.

0177<figref idref="DRAWINGS">FIG. 2B</figref> shows additional details regarding training the deep learning neural network. In <figref idref="DRAWINGS">FIG. 2B</figref>, the historical market scenarios (e.g., a set of calculated market factor changes for each rolling window period of the selected time period bucket) may be obtained at <b>202</b>. In one implementation, a reference to a historical market factor changes data structure (e.g., an array of arrays where each element of the outer array corresponds to a training data point of historical market factor changes for a rolling window period, and each element of the inner array corresponds to a historical return of a market factor during the rolling window period) with the calculated historical market factor changes may be obtained.

0178A determination may be made at <b>206</b> whether there remain hyper-parameters options of the deep learning neural network to analyze. For example, the hyper-parameters of the deep learning neural network may include the number of layers and/or perceptrons in each layer of encoder and/or decoder, the dimensionality of latent space, and/or the like. In one implementation, the machine learning simulated scenario processing request may be parsed (e.g., using PHP commands) to determine hyper-parameters options to test (e.g., based on the value of the hyper_parameters_to_test field). If there remain hyper-parameters options to analyze, the next set of hyper-parameters (e.g., specified in a hyper_parameters_option field) for the deep learning neural network may be selected for testing at <b>210</b>.

0179A determination may be made at <b>212</b> whether a termination condition for training the deep learning neural network has been reached. In various implementations, the termination condition may comprise one or more of a specified number of training iterations, a specified training time, a specified minimum deep learning neural network performance rank, and/or the like.

0180If the termination condition for training the deep learning neural network has not been reached, a determination may be made at <b>214</b> whether there remain more training data points to use for training the deep learning neural network. In one implementation, each of the training data points in the historical market factor changes data structure may be used for training. If there remain more training data points to use, the next training data point (e.g., historical market factor changes for a rolling window period) may be selected at <b>218</b>.

0181Input and output layers of the deep learning neural network may be set to the selected training data point at <b>222</b>. In one implementation, the input and output layers may be f-dimensional layers, where f is the number of market factors. For example, the input and output layers may be set to the values of the inner array of the historical market factor changes data structure corresponding to the selected training data point.

0182The deep learning neural network may be trained on the selected training data point using a variational autoencoder to generate a set of Gaussian-Mixture latent variables at <b>226</b>. In one embodiment, the deep learning neural network may be trained using backpropagation with a specified loss function. In one implementation, the loss function may be chosen to minimize mean squared error of the Euclidean distances of individual market factors return values to the historical realized return values, and/or to minimize the variance of joint distributions across encoded market factors between simulated and historical markets in the latent space (e.g., the KL divergence score). In one embodiment, the loss function on factor returns may be in the original factor space, while the KL divergence constraint plays the role in the latent space (lower dimensional space) to map the encoded factors to Gaussian or Gaussian mixture distribution. In one implementation, the encoder and the decoder may be set to have the same structures and during the training process their weights may be synchronized, so that half of the total weights have to be learned to reduce the complexity of deep network training.

0183Once the deep learning neural network is trained on the training data points, performance of the trained deep learning neural network may be evaluated at <b>230</b>. For example, the performance of the trained deep learning neural network may be evaluated using a set of testing data points (e.g., available data points may be split into 75% training data points and 25% testing data points). In one embodiment, the trained deep learning neural network may be assigned a performance rank (e.g., a score). In one implementation, differences between market factor changes at the input layer and market factor changes at the output layer may be evaluated using the Kolmogorov-Smirnov (KS) test for individual market factors and/or Cramer test for joint distribution to calculate a performance score for the trained deep learning neural network. For example, for the KS test and/or the Cramer test, the lower the scores, the better the performance. Accordingly, the scores may be sorted in ascending order and performance of deep learning neural networks may be ranked in the hyperparameter tuning process such that the deep learning neural network with the optimal performance is the one with the highest rank.

0184If the termination condition for training the deep learning neural network has been reached, the next set of hyper-parameters, if any, for the deep learning neural network may be analyzed at <b>206</b>.

0185The neural network with the optimal performance may be selected at <b>234</b>. In one implementation, the deep learning neural network with the best (e.g., highest) performance rank may be selected to simulate market scenarios.

0186<figref idref="DRAWINGS">FIG. 3</figref> shows an architecture for the MLPO. In <figref idref="DRAWINGS">FIG. 3</figref>, an embodiment of how a deep learning neural network may be structured is illustrated. The deep learning neural network may have an input layer <b>301</b>. The input layer may be an f-dimensional layer, where f is the number of market factors. Market factor changes data provided to the input layer may be converted using an encoder <b>305</b> into latent space variables <b>310</b>. The encoder may comprise one or more hidden layers, and the number of hidden layers and/or the number of perceptrons in each layer may be hyper-parameters tuned for optimal performance. The latent space variables may comprise a hidden layer of Gaussian mixtures, and the dimensionality of latent space may be a hyper-parameter tuned for optimal performance. In one embodiment, the latent space may be implemented using a Gaussian distribution and a mixture layer. The mixture layer may be designed to introduce richer correlations across encoded factors and thus approximately formulate a Gaussian mixture distribution. The simulation may be conducted by sampling from the Gaussian distribution, then the samples may be transferred to a near Gaussian mixture space via the mixture layer, and then sent to a decoder that maps to the original factor space. In another embodiment, the latent space may be implemented using a standard Gaussian mixture distribution (GM), where the mixture weights are hyper-parameters to be fine-tuned. The simulation may be conducted by sampling from the GM, and then the samples may be sent to a decoder. Latent space variables data may be converted using a decoder <b>315</b> into market factor changes data in an output layer <b>320</b>. The decoder may comprise one or more hidden layers, and the number of hidden layers and/or the number of perceptrons in each layer may be hyper-parameters tuned for optimal performance. The output layer may be an f-dimensional layer, where f is the number of market factors.

0187<figref idref="DRAWINGS">FIG. 4</figref> shows a logic flow illustrating embodiments of a machine learning simulated scenario processing (MLSSP) component for the MLPO. In <figref idref="DRAWINGS">FIG. 4</figref>, a machine learning simulated scenario processing request may be obtained at <b>401</b>. For example, the machine learning simulated scenario processing request may be obtained as a result of an administrative user requesting generation of a set of simulated scenarios.

0188A rolling window period length may be determined at <b>405</b>. In one embodiment, historical data may be analyzed to calculate changes to a set of market factors during each rolling window period of a specified rolling window period length. In one implementation, the machine learning simulated scenario processing request may be parsed (e.g., using PHP commands) to determine historical data to analyze (e.g., based on the value of the historical_data field) and/or the rolling window period length to use for analysis (e.g., based on the value of the rolling_window_period_length field). For example, the machine learning simulated scenario processing request may specify that the last 30 years of historical data should be analyzed using 6 month rolling window periods.

0189Market factors to process may be determined at <b>409</b>. For example, market factors may include interest rates, credit spread, oil price, equity indices, and/or the like, and changes to the market factors during a rolling window period jointly describe a market scenario (e.g., a historical market scenario for historical changes, a simulated market scenario for simulated changes). In one implementation, the machine learning simulated scenario processing request may be parsed (e.g., using PHP commands) to determine the market factors to process (e.g., based on the value of the market_factors field). In another implementation, a set of default market factors to process may be specified in a configuration setting.

0190A determination may be made at <b>413</b> whether there remain market factors to process. In one implementation, each of the market factors may be processed. If there remain market factors to process, the next market factor (e.g., 6 month change in interest rates) may be selected for processing at <b>417</b>.

0191A determination may be made at <b>421</b> whether there remain rolling window periods to analyze. In one implementation, historical data for the selected market factor may be analyzed during each of the rolling window periods. If there remain rolling window periods to analyze, the next rolling window period may be selected for analysis at <b>425</b>. For example, the next rolling window period may be two specific time points (e.g., days) 6 months apart.

0192A determination may be made at <b>429</b> whether data for the selected rolling window period is available. In one implementation, this determination may be made based on whether historical data for the selected market factor is available for both time points (e.g., for both days) of the selected rolling window period.

0193If historical market factor data is unavailable for one or both time points (e.g., days) of the selected rolling window period, the missing data may be imputed using a machine learning (e.g., k-Nearest Neighbors (k-NN)) method at <b>433</b> based on market factor data for other time points (e.g., for other days). In one implementation, the k-NN method may be used to match records (e.g., a record may be a set of market factors for a time point) with missing data points (e.g., a missing data point may be a missing market factor data for a time point) in a multi-dimensional space. For example, the missing data for the selected market factor for a time point may be calculated as the average of values of the selected market factor for k nearest neighbors of the time point as determined based on similarity of the other market factors.

0194Change to the selected market factor during the selected rolling window period may be calculated at <b>437</b>. In one implementation, the change to the selected market factor during the selected rolling window period may be calculated by determining the delta between values of the selected market factor at the two time points of the selected rolling window period. For example, the 6 month change in 5 year interest rates for the rolling window period between Jan. 7, 2019 and Jul. 8, 2019, may be calculated by subtracting the US Treasury 5 Year Par Yield on Jan. 7, 2019 from the US Treasury 5 Year Par Yield on Jul. 8, 2019. In another example, the 6 month change in 5 year interest rates for the rolling window period between Jan. 8, 2019 and Jul. 9, 2019, may be calculated by subtracting the US Treasury 5 Year Par Yield on Jan. 8, 2019 from the US Treasury 5 Year Par Yield on Jul. 9, 2019.

0195Once changes to each of the market factors during each of the rolling window periods are calculated, a determination may be made at <b>441</b> regarding the type of time period buckets to utilize. In one embodiment, fixed length time period buckets may be utilized. In another embodiment, variable length time period buckets may be utilized. In one implementation, the machine learning simulated scenario processing request may be parsed (e.g., using PHP commands) to determine the type of time period buckets to utilize (e.g., based on the value of the time_period_bucket_type field).

0196If fixed length time period buckets are utilized, the length of time period buckets to utilize may be determined at <b>445</b>. In one implementation, the machine learning simulated scenario processing request may be parsed (e.g., using PHP commands) to determine the length of time period buckets to utilize (e.g., based on the value of the time_period_bucket_length field). For example, the machine learning simulated scenario processing request may specify that historical market scenarios generated from the last 30 years of historical data (e.g., using calculated changes from <b>437</b>) should be split using 6 month long time period buckets, resulting in 60 time period buckets to process. It is to be understood that the length of time period buckets is independent of the rolling window period length (e.g., the two lengths may be the same or may be different).

0197If variable length time period buckets are utilized, time period buckets reflective of changes in volatilities and correlations of the historical data may be determined at <b>449</b>. In one implementation, the time period buckets may be selected by judging the overall goodness of fit between simulated data from the time period buckets and historical data. KS tests and Cramer test may be performed jointly between the simulated market scenarios and the historical market scenarios. The splitting into time period buckets may support the objective function of minimizing the KS test values of the marginal distributions and Cramer test value of the multivariate distribution of simulated market scenarios vs. realized historical market scenarios. For example, the machine learning simulated scenario processing request may specify that historical market scenarios generated from the last 30 years of historical data (e.g., using calculated changes from <b>437</b>) should be split by bucketing historical market scenarios from the same economic cycle (e.g., early cycle, mid cycle, late cycle, recession) together to summarize the changes in volatilities and correlation structure. In some implementations, the number of time period buckets may be determined by balancing the amount of historical data vs. the number of market factors. For example, given that data frequency is constant, as the number of market factors increases the time duration utilized for each time period bucket increases.

0198The historical market scenarios may be bucketed in accordance with the determined time period buckets at <b>453</b>. In one implementation, each historical market scenario may be assigned a bucket identifier that specifies the time period bucket associated with the respective historical market scenario.

0199A determination may be made at <b>457</b> whether there remain time period buckets to process. In one implementation, each of the time period buckets may be processed. If there remain time period buckets to process, the next time period bucket (e.g., historical market scenarios associated with the next 6 month long time period bucket) may be selected for processing at <b>461</b>.

0200A determination may be made at <b>465</b> whether there remain market factors to process. In one implementation, each of the market factors may be processed. If there remain market factors to process, the next market factor (e.g., 6 month change in interest rates) may be selected for processing at <b>469</b>.

0201A distribution to use for the selected market factor during the selected time period bucket may be determined using the selected market factor's goodness of fit at <b>473</b>. For example, a distribution to use may be Gaussian, log-normal, and/or the like. In one implementation, goodness of fit calculation may be performed to determine which distribution fits the historical returns (e.g., the calculated changes) for each time bucket using Kolmogorov-Smirnov Test (KS test) and/or Cramer test. For example, the distribution to use may be determined as the one with the best KS test performance for each of the individual factor and/or Cramer test performance for the overall distribution.

0202The determined marginal distribution to use may be fitted to the historical returns of the selected market factor during the selected time period bucket at <b>477</b>. For example, the determined marginal distribution to use may be a Gaussian distribution. Accordingly, and a of the Gaussian distribution may be determined. In one implementation, the Gaussian distribution may be fitted by calculating μ and σ of the historical returns (e.g., of the calculated changes) of the selected market factor during the selected time bucket. In one embodiment, the fitting may be implemented using Apache Spark. In some implementations, the fitting for multiple time buckets may occur in parallel. For example, a mapper function that performs the fitting and simulation for each time bucket and utilizes group by on time buckets may be implemented as follows:

0000<tables id="TABLE-US-00015" num="00015"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="center" /><colspec colname="2" colwidth="189pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>reducer_simulator = generate_reducer_func(sim_id, 1 + </entry></row><row><entry /><entry>num_sim_row / num_buckets) us_tsy_sim =</entry></row><row><entry /><entry>us_tsy.map(lambda x: (x[0], x[2])).groupByKey</entry></row><row><entry /><entry>(num_buckets).flatMap(reducer_simulator)</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0203A copula for the processed market factors for the selected time period bucket may be determined at <b>481</b>. For example, the copula may be utilized to capture the dependency structure between marginal distributions of the market factors during the selected time period bucket. In one implementation, the copula may be fitted as follows: <ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0000"><ul id="ul0010" list-style="none"><li id="ul0010-0001" num="0204">1. Feed factor return through its own CDF function to a distribution of the grades; a uniformly distributed random variable</li><li id="ul0010-0002" num="0205">2. Copula of a set of factors will be the joint distribution of factors' grades. Joint=Copula+Marginals <br /> For example, the SN R package may be utilized to determine the copula and supports Gaussian, skewed Gaussian, T and Skewed T Copula. </li></ul></li></ul>

0206A multi-variate mixture model for the selected time period bucket may be trained at <b>485</b>. For example, the multi-variate mixture model may be a multi-variate Gaussian mixture model. In one implementation, in Python, scipy.stats.multivariate_normal may be used for the different time period buckets to formulate a multi-variate Gaussian mixture. In another implementation, the SN R package may be utilized. In another implementation, training of the Gaussian mixture models may be implemented using Apache Spark. For example, the multi-variate mixture model for the selected time period bucket may be trained using the org.apache.spark.ml.clustering.GaussianMixture.fit( ) function, and the multi-variate mixture model may take the form of a org.apache.spark.ml.clustering.GaussianMixture multi-variate mixture datastructure. In one embodiment, the marginal distribution may be fitted to optimize the distributional families and their respective distributional parameters to minimize the KS test value between the marginal distribution and the historical distribution. In selecting various probability density functions such as Gaussian, skewed Gaussian, student T or skewed T copula, Cramer test and KS test values may be applied to minimize the multivariate and/or marginal distributions between simulated and historical data.

0207The number of market scenarios to simulate may be determined at <b>489</b>. For example, 1,000 scenarios may be simulated (e.g., resulting in 60,000 total simulated scenarios over 60 time period buckets). In one implementation, the machine learning simulated scenario processing request may be parsed (e.g., using PHP commands) to determine the number of market scenarios to simulate for each of the time period buckets (e.g., based on the value of the number_of_simulated_market_scenarios field). In another implementation, the number of market scenarios to simulate for each of the time period buckets may be specified in a configuration setting. In another implementation, the number of market scenarios to simulate may differ for different time period buckets.

0208A determination may be made at <b>493</b> whether there remain market scenarios to simulate. If so, a set of simulated market factor changes may be generated using the multi-variate mixture model at <b>495</b>. In one implementation, in Python, scipy.stats.multivariate_normal may be used to generate the set of simulated market factor changes. In another implementation, the SN R package may be utilized. In an alternative implementation, the set of simulated market factor changes may be generated using the scikit-learn sklearn.mixture.BayesianGaussianMixture.sampleQ method.

0209The simulated scenario may be stored in a database at <b>499</b>. In one implementation, the simulated scenario may be stored (e.g., in a batch with other simulated scenarios) via a scenario results store request.

0210<figref idref="DRAWINGS">FIG. 5</figref> shows a logic flow illustrating embodiments of a decision tree ensembles training (DTET) component for the MLPO. In <figref idref="DRAWINGS">FIG. 5</figref>, a decision tree ensembles training request may be obtained at <b>501</b>. For example, the decision tree ensembles training request may be obtained as a result of an administrative user requesting training of decision tree ensembles.

0211Requested predictive capabilities may be determined at <b>505</b>. For example, predictive capabilities may include estimating conditional Beta for a security, estimating conditional default for a security, and/or the like. In one implementation, the decision tree ensembles training request may be parsed (e.g., using PHP commands) to determine the requested predictive capabilities (e.g., based on the value of the predictive_capability_type fields). In another implementation, the requested predictive capabilities may be specified in a configuration setting.

0212A universe of securities to process may be determined at <b>509</b>. For example, the universe of securities (e.g., securities in the S&amp;P 500 Index) may include a list of equities, fixed income, and/or the like securities. In one implementation, the decision tree ensembles training request may be parsed (e.g., using PHP commands) to determine the universe of securities (e.g., based on the value of the universe_of_securities field). In another implementation, the universe of securities may be specified in a configuration setting.

0213A determination may be made at <b>513</b> whether there remain securities to process. In one implementation, each of the securities in the universe of securities may be processed. If there remain securities to process, the next security may be selected for processing at <b>517</b>.

0214A determination may be made at <b>521</b> whether there remain predictive capabilities to train for the selected security. In one implementation, each of the requested predictive capabilities for the selected security may be trained. If there remain predictive capabilities to train, the next predictive capability may be selected for training at <b>525</b>.

0215Features to use for training decision tree ensembles that provide the selected predictive capability for the selected security may be determined at <b>529</b>. For example, different features may be used when training decision tree ensembles for fixed income and equity securities, for conditional Beta and conditional default. See <figref idref="DRAWINGS">FIGS. 6A-D</figref> for examples of features that may be used when training decision tree ensembles. In one implementation, the decision tree ensembles training request may be parsed (e.g., using PHP commands) to determine the features to use for training (e.g., based on the value of the training_features field). In another implementation, the features to use for training may be specified in a configuration setting.

0216A determination may be made at <b>533</b> whether sufficient training data is available for training decision tree ensembles that provide the selected predictive capability for the selected security. For example, if the features to use for training include pricing history features, a determination may be made if sufficient pricing history data for the selected security is available.

0217If sufficient training data is available for training decision tree ensembles that provide the selected predictive capability for the selected security, the training data may be obtained at <b>537</b>. In one implementation, a reference to a training data datastructure may be obtained. For example, the training data datastructure may be structured as follows:

0000<tables id="TABLE-US-00016" num="00016"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="6"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="42pt" align="left" /><colspec colname="4" colwidth="35pt" align="left" /><colspec colname="5" colwidth="21pt" align="left" /><colspec colname="6" colwidth="42pt" align="left" /><thead><row><entry namest="1" nameend="6" align="center" rowsep="1" /></row><row><entry /><entry /><entry>Feature_1_</entry><entry>Feature_2_</entry><entry /><entry>Feature_N_</entry></row><row><entry /><entry>Target</entry><entry>ID:Value</entry><entry>ID:Value </entry><entry /><entry>ID:Value</entry></row><row><entry /><entry>(Beta)</entry><entry>(cashmta)</entry><entry>(ni_ta)</entry><entry>. . .</entry><entry>(sec45)</entry></row><row><entry namest="1" nameend="6" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Data Point 1</entry><entry>1.1</entry><entry>1:0.3</entry><entry>2:0.5</entry><entry /><entry>4:1</entry></row><row><entry>Data Point 2</entry><entry>1.4</entry><entry>1:0.2</entry><entry>2:0.6</entry><entry /><entry>4:0</entry></row><row><entry namest="1" nameend="6" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0218As an example of training data for a muni instrument for estimating Beta, the Beta of the instrument returns vs. muni index average return over a three month time period may be calculated using rolling 3 month daily returns. This set of Beta is the target variable. The market scenarios leading up to the return period are the trailing market scenario features. Instrument to index relative features are used to capture idiosyncratic risk (e.g., some muni instruments spread will trade richer, others cheaper relative to the muni index average spread). The market scenarios within the return period are also used as features.

0219A determination may be made at <b>541</b> whether a termination condition for training decision tree ensembles that provide the selected predictive capability for the selected security has been reached. In various implementations, the termination condition may comprise one or more of a specified number of training iterations, a specified training time, a specified minimum performance rank, and/or the like. For example, a performance rank may be determined by calculating R²for the decision tree ensembles (e.g., available data points may be split into 75% training data points and 25% testing data points for validation).

0220If the termination condition for training the decision tree ensembles has not been reached, a determination may be made at <b>545</b> whether there remain more training data points to use for training the decision tree ensembles. In one implementation, each of the training data points in the training data datastructure may be used for training. If there remain more training data points, the next training data point (e.g., Beta and feature values) may be selected at <b>549</b>. The decision tree ensembles may be trained on the selected training data point using gradient boosting at <b>553</b>. In one implementation, the XGBoost library may be used to train the decision tree ensembles using the training data datastructure. For example, in Python, using the XGBoost package, the decision tree ensembles may be trained as follows:

0000<tables id="TABLE-US-00017" num="00017"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Training:</entry></row><row><entry>def exe_xgb(ft_pd):</entry></row><row><entry> data = ft_pd.copy( )</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><tbody valign="top"><row><entry> X</entry><entry>= data.iloc[:, 1:]</entry></row><row><entry> y</entry><entry>= data.iloc[:, ∅]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=∅.25)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><tbody valign="top"><row><entry> model</entry><entry>= xgb.XGBRegressor( )</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> model.fit(X_train, y_train)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><tbody valign="top"><row><entry> score</entry><entry>= model.score(X_test, y_test)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> return model, score</entry></row><row><entry>Scoring:</entry></row><row><entry>def calculate_inst(x):</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row><entry> key_cusip </entry><entry>= x[∅]</entry></row><row><entry> ft_no_sim </entry><entry>= x[1]</entry></row><row><entry> model_cusip </entry><entry>= x[2]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> Row_list =[ ]</entry></row><row><entry> features_pd = ft_sim_pd_orig.copy( )</entry></row><row><entry> scoring_df  = features_pd[features_pd.columns[:ft_sim_ini]]</entry></row><row><entry> ft_row_num = len(features_pd)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry> ft_left </entry><entry>= ft_no_sim.values * ft_row_num</entry></row><row><entry> ft_left </entry><entry>= pd.DataFrame(ft_left, columns=list(ft_no_sim.columns))</entry></row><row><entry> ft_right </entry><entry>= features_pd[features_pd.columns[ft_sim_ini:]]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> X_scoring = pd.concat([ft_left, ft_right], axis=1)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row><entry> y_scoring </entry><entry>= model_cusip.predict(X_scoring)</entry></row><row><entry> y_scoring </entry><entry>= pd.DataFrame(y_scoring, columns=[′measure_value′])</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> y_scoring[′asset_id′]   = key_cusip</entry></row><row><entry> y_scoring_complete = scoring_df.join(y_scoring)</entry></row><row><entry> y_scoring_complete = y_scoring_complete[col_order]</entry></row><row><entry> for index, rows in y_scoring_complete.iterrows( ):</entry></row><row><entry>  my_list =[int(rows.asset_id), int(rows.market_id), </entry></row><row><entry>  float(rows.measure_value)]</entry></row><row><entry>  Row_list.append(my_list)</entry></row><row><entry> return Row_list</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0221If the termination condition for training the decision tree ensembles has been reached, the trained decision tree ensembles that provide the selected predictive capability for the selected security may be stored in a database at <b>557</b>. In one implementation, the decision tree ensembles may be stored via a decision tree ensembles store request.

0222<figref idref="DRAWINGS">FIGS. 6A-D</figref> show implementation case(s) for the MLPO. In <figref idref="DRAWINGS">FIGS. 6A-D</figref>, features that may be used for estimating conditional Beta and/or conditional default are illustrated.

0223<figref idref="DRAWINGS">FIG. 7A</figref> shows a logic flow illustrating embodiments of an expected returns calculation (ERC) component for the MLPO. In <figref idref="DRAWINGS">FIG. 7A</figref>, an expected returns calculation request may be obtained at <b>701</b>. For example, the expected returns calculation request may be obtained as a result of an administrative user requesting calculation of expected returns for a universe of securities under simulated scenarios (e.g., of a simulation).

0224The universe of securities to process may be determined at <b>705</b>. For example, the universe of securities (e.g., securities in the S&amp;P 500 Index) may include a list of equities, fixed income, and/or the like securities. In one implementation, the expected returns calculation request may be parsed (e.g., using PHP commands) to determine the universe of securities (e.g., based on the value of the universe_of_securities field). In another implementation, the universe of securities may be specified in a configuration setting.

0225A determination may be made at <b>709</b> whether there remain securities to process. In one implementation, each of the securities in the universe of securities may be processed. If there remain securities to process, the next security may be selected for processing at <b>713</b>.

0226Simulated market scenarios to analyze may be determined at <b>715</b>. In one implementation, the expected returns calculation request may be parsed (e.g., using PHP commands) to determine the simulated market scenarios to analyze (e.g., based on the values of the simulation_identifier field and/or the simulated_scenarios field). In another implementation, the simulated market scenarios to analyze may be specified in a configuration setting.

0227A determination may be made at <b>717</b> whether there remain simulated market scenarios to analyze. In one implementation, each of the simulated market scenarios (e.g., of the simulation) may be analyzed. If there remain simulated market scenarios to analyze, the next market scenario (e.g., from the 60,000 simulated scenarios) may be selected for analysis at <b>721</b>.

0228Features to utilize for conditional Beta estimation for the selected security under the selected simulated market scenario may be determined at <b>725</b>. For example, different features may be used when estimating conditional Beta for fixed income and equity securities. In one implementation, the features that were used for training decision tree ensembles for estimating conditional Beta, as discussed with regard to <figref idref="DRAWINGS">FIG. 5</figref>, may be utilized. In one embodiment, the calculation of conditional Beta for different assets may be parallelized using Apache Spark. The mapper function may partition by asset_id, such as CUSIP, and may use XGBoost to train a model for each asset. The data frames for the XGBoost models may be stored as binary data as part of the calculation workflow to a relational database concurrently. The scoring process that generates a distribution of Beta for each asset may also be parallelized. The data storage design and parallel computing implementation of the MLPO allows each asset to have its own set of residuals. The residuals may be further analyzed to ensure that there is no systematic bias overstating or understating the simulated Beta, and/or that the residuals are not correlated with the simulated Beta. The sum of the simulated Beta from common risk factors and the residuals may be stored as the final simulated Beta. For example, the XGBoost model may be executed as follows:

0000<tables id="TABLE-US-00018" num="00018"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>model_function = generate_model(model_column, instrument_column, </entry></row><row><entry>ratio_column, factor_column, delta_length, time_series_length, </entry></row><row><entry>delta_name, feature_engineering_function_name, xgb_function_name)</entry></row><row><entry>conditional_beta_model = raw_data.rdd \</entry></row><row><entry>      .map(extract cusip)\</entry></row><row><entry>      .groupByKey(num_partitions)\</entry></row><row><entry>      .map(function_including_feature_engineering_and_xgb)</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0229A determination may be made at <b>729</b> whether sufficient estimation data is available for estimating conditional Beta for the selected security under the selected simulated market scenario. In one implementation, a determination may be made whether instrument data for the selected security during the time period associated with the selected simulated market scenario is available. For example, if the features to use for conditional Beta estimation include pricing history features, a determination may be made if pricing history data for the selected security is available during the time period associated with the selected simulated market scenario. In another implementation, a determination may be made whether decision tree ensembles for estimating conditional Beta for the selected security exist. For example, if sufficient training data was not available, decision tree ensembles for estimating conditional Beta for the selected security may not have been trained.

0230If sufficient estimation data is available (e.g., decision tree ensembles exist and pricing history data is available), the selected security's conditional Beta may be estimated using the decision tree ensembles trained to estimate conditional Beta for the selected security at <b>733</b>. In one implementation, the decision tree ensembles may be queried to predict the selected security's conditional Beta based on the estimation data.

0231If sufficient estimation data is not available (e.g., decision tree ensembles do not exist or pricing history data is not available), the selected security's conditional Beta may be estimated using a machine learning (ML) method at <b>737</b>. In one implementation, the k-NN method may be used to estimate conditional Beta for the selected security by finding the closest modeled security to the selected security, and using the closest modeled security's estimated conditional Beta as a proxy of the selected security's estimated conditional Beta. For example, the features to utilize for conditional Beta estimation may be used as inputs to the k-NN to find the closest modeled security.

0232Features to utilize for conditional default probability estimation for the selected security under the selected simulated market scenario may be determined at <b>741</b>. For example, different features may be used when estimating conditional default probability for fixed income and equity securities. In one implementation, the features that were used for training decision tree ensembles for estimating conditional default probability, as discussed with regard to <figref idref="DRAWINGS">FIG. 5</figref>, may be utilized.

0233A determination may be made at <b>745</b> whether sufficient estimation data is available for estimating conditional default probability for the selected security under the selected simulated market scenario. In one implementation, a determination may be made whether instrument data for the selected security during the time period associated with the selected simulated market scenario is available. For example, if the features to use for conditional default probability estimation include pricing history features, a determination may be made if pricing history data for the selected security is available during the time period associated with the selected simulated market scenario. In another implementation, a determination may be made whether decision tree ensembles for estimating conditional default probability for the selected security exist. For example, if sufficient training data was not available, decision tree ensembles for estimating conditional default probability for the selected security may not have been trained. In one embodiment, the calculation of default probability for different assets may be parallelized using Apache Spark. The mapper function may partition by asset_id, such as CUSIP, and may use XGBoost to train a model for each asset. Features, such as company financials data and macro factors, may be distributed by asset id. The data frames for the XGBoost models may be stored as binary data as part of the calculation workflow to a relational database concurrently. The scoring process that generates a default probability distribution for each asset under various simulated market scenarios may also be parallelized with factor simulation data broadcasted to the worker nodes. The data storage design and parallel computing implementation of the MLPO allows each instrument to have its own XGBoost model. For example, the XGBoost model may be executed as follows:

0000<tables id="TABLE-US-00019" num="00019"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>model_function = generate_model(model_column, instrument_column, </entry></row><row><entry>ratio_column, factor_column, delta_length, time_series_length, </entry></row><row><entry>delta_name, feature_engineering_function_name, xgb_function_name, </entry></row><row><entry>sector_column, default_probability_column)</entry></row><row><entry>conditional_default_model = raw_data.rdd \</entry></row><row><entry>      .map(extract cusip)\</entry></row><row><entry>      .groupByKey(num_partitions)\</entry></row><row><entry>      .map(function_including_feature_engineering_and_xgb)</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0234If sufficient estimation data is available (e.g., decision tree ensembles exist and pricing history data is available), the selected security's conditional default probability may be estimated using the decision tree ensembles trained to estimate conditional default probability for the selected security at <b>749</b>. In one implementation, the decision tree ensembles may be queried to predict the selected security's conditional default probability based on the estimation data.

0235If sufficient estimation data is not available (e.g., decision tree ensembles do not exist or pricing history data is not available), the selected security's conditional default probability may be estimated using a machine learning (ML) method at <b>753</b>. In one implementation, the k-NN method may be used to estimate conditional default probability for the selected security by finding the closest modeled security to the selected security, and using the closest modeled security's estimated conditional default probability as a proxy of the selected security's estimated conditional default probability. For example, the features to utilize for conditional default probability estimation may be used as inputs to the k-NN to find the closest modeled security.

0236Default for the selected security under the selected simulated market scenario may be simulated at <b>757</b>. In one implementation, the value of a random variable that has values corresponding to Default (e.g., with probability equal to: the selected security's conditional default probability) and No Default (e.g., with probability equal to: 1—the selected security's conditional default probability) expected return types may be simulated. For example, the value of the random variable may be randomly generated from a standard normal distribution as a number from 0 to 1. If the number is smaller than the estimated conditional default probability, the default value is set to 1 (Default), otherwise to 0 (No Default) (e.g., if the conditional default probability for market scenario <b>10001</b> is 10% and the randomly generated number is 0.312, then the asset's default flag for scenario <b>10001</b> is set to 0 (No Default; if the randomly generated number is 0.05, which is smaller than 0.1 (10% default probability), then the asset's default flag for scenario <b>10001</b> is set to 1 (Default)).

0237A determination may be made at <b>761</b> whether the expected return type for the selected security under the selected simulated market scenario is Default or No Default. If the expected return type is No Default, an expected return for the selected security under the selected simulated market scenario may be calculated at <b>765</b>. For example, the expected return (ER) may be calculated as follows:

0238Fixed Income Assets—No Default:

0000<maths id="MATH-US-00001" num="00001"><math overflow="scroll"><mrow><mi>ER</mi><mo>=</mo><mrow><mrow><munderover><mo>∑</mo><mrow><mi>factor</mi><mo>=</mo><mn>1</mn></mrow><mi>n</mi></munderover><mo>⁢</mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo>⁢</mo><mrow><mrow><mi>Exposure</mi><mo>⁡</mo><mrow><mo>(</mo><mrow><mi>f</mi><mo>,</mo><mi>i</mi></mrow><mo>)</mo></mrow></mrow><mo>×</mo><mi>Conditional</mi><mo>⁢</mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo>⁢</mo><mrow><mi>Beta</mi><mo>⁡</mo><mrow><mo>(</mo><mrow><mi>i</mi><mo>,</mo><mi>m</mi></mrow><mo>)</mo></mrow></mrow><mo>×</mo><mi>Simulated</mi><mo>⁢</mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo>⁢</mo><mi>Factor</mi><mo>⁢</mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo>⁢</mo><mrow><mi>Change</mi><mo>⁡</mo><mrow><mo>(</mo><mrow><mi>f</mi><mo>,</mo><mi>m</mi></mrow><mo>)</mo></mrow></mrow></mrow></mrow><mo>+</mo><mi>Carry</mi><mo>+</mo><mi>Rolldown</mi></mrow></mrow></math></maths><img file="US2022101438A1_D0001.tif" />

0239Equity Assets—No Default:

0000<br /><i>ER</i>=Conditional Beta(<i>i,m</i>)×Simulated Return of Equity Index(<i>f,m</i>)<ul id="ul0011" list-style="none"><li id="ul0011-0001" num="0000"><ul id="ul0012" list-style="none"><li id="ul0012-0001" num="0240">Where:</li><li id="ul0012-0002" num="0241">f is the number of market factors for which an instrument has price sensitivities</li><li id="ul0012-0003" num="0242">i is the number of instruments in the investable universe</li><li id="ul0012-0004" num="0243">Exposure is a f by i matrix that contains instruments' return sensitivities to market factors. They are calculated as the Beta of instruments' return to the market factor change. For example, for fixed income instruments, the exposure to interest rate risk factors may be option adjusted durations. They may be calculated by moving the rates up and down “shocking the yield curve”, discounting the cashflows of the bond while adjusting for optionality. The bigger the differences in present values for a given unit of interest rate shock, the higher the duration, aka “return sensitivity to rates”.</li><li id="ul0012-0005" num="0244">m is the number of simulated market scenarios</li><li id="ul0012-0006" num="0245">For example, each instrument i may have a different Beta along each simulated market scenario</li><li id="ul0012-0007" num="0246">Conditional Beta is a i by m matrix</li><li id="ul0012-0008" num="0247">Simulated Factor Change is a f by m matrix; each market factor may have a simulated change value along each market scenario</li><li id="ul0012-0009" num="0248">Equity Index is a market factor simulated along with other market factors</li><li id="ul0012-0010" num="0249">Conditional beta may be calculated for individual equities against their respective equity indices for each simulated market scenario.</li></ul></li></ul>

0250If the expected return type is Default, an expected return for the selected security under the selected simulated market scenario may be calculated at <b>769</b>. For example, the expected return (ER) may be calculated as follows:

0251Fixed Income Assets—Default:

0000<maths id="MATH-US-00002" num="00002"><math overflow="scroll"><mrow><mi>ER</mi><mo>=</mo><mfrac><mrow><mo>(</mo><mrow><mrow><mo>(</mo><mrow><mi>Recovery</mi><mo>⁢</mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo>⁢</mo><mi>Rate</mi><mo>×</mo><mn>100</mn></mrow><mo>)</mo></mrow><mo>-</mo><mi>Price</mi></mrow><mo>)</mo></mrow><mi>Price</mi></mfrac></mrow></math></maths><img file="US2022101438A1_D0002.tif" />

0252Equity Assets—Default:

0000<maths id="MATH-US-00003" num="00003"><math overflow="scroll"><mrow><mi>ER</mi><mo>=</mo><mn>0</mn></mrow></math></maths><maths id="MATH-US-00003-2" num="00003.2"><math overflow="scroll"><mrow><mi>Where</mi><mo>⁢</mo><mstyle><mtext>:</mtext></mstyle></mrow></math></maths><maths id="MATH-US-00003-3" num="00003.3"><math overflow="scroll"><mrow><mrow><mi>Recovery</mi><mo>⁢</mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo>⁢</mo><mi>Rate</mi></mrow><mo>=</mo><mrow><mn>1</mn><mo>-</mo><mfrac><mrow><mi>Credit</mi><mo>⁢</mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo>⁢</mo><mi>Spread</mi></mrow><mrow><mi>Conditional</mi><mo>⁢</mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo>⁢</mo><mi>Default</mi><mo>⁢</mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo>⁢</mo><mi>Probability</mi></mrow></mfrac></mrow></mrow></math></maths>

0253The calculated expected returns may be stored in a database at <b>773</b>. In one implementation, the calculated expected returns may be stored via an expected returns store request.

0254<figref idref="DRAWINGS">FIG. 7B</figref> illustrates embodiments of a computation engine architecture that supports and implements the business logic. In various implementations the computation engine may be characterized by the following features:

02551: Parallel on Parallel Hierarchy and Flexible Calculation Dependencies: Use Apache AirFlow to define calculation workflow and enable concurrent processing of a single or multiple calculation module(s) and flexible dependencies. For example, 3 month, 6 month and 12 months (e.g., based on rolling window period length) simulations from multiple factor simulation models may be processed in parallel. The dependency management allows risk data maintenance and pushing risk analytics to a cloud based datamart (e.g., SnowFlake) upon the completion of asset return simulation for assets across time horizons and simulation models. Furthermore, within each calculation module, Apache Spark may be used to enable parallel computing of instruments. For example, to calculate 12 month asset return simulation for the deep learning model (asim1Y_DL_CMA), over 130,000 bond instruments may be distributed across hundreds of worker nodes in the cloud. This type of parallel on top of parallel technology approach maximizes the utilization of cloud based computing power and provides control and flexibility for defining calculation dependencies.

02562: Self-Service: Computation capabilities may be authored by domain experts. Team members may orchestrate and assemble the capabilities and declare dependencies with custom built WDL (Workflow Declaration Language). In one implementation, YAML may be used as the WDL.

02573: Heterogenous Platforms: Various computation platforms such as parallel computing using Apache Spark using Scala/Java/Python, distributed computing on Virtual Servers using Golang, SQL and shell scripts, and/or the like may be supported.

02584: Event-Based: Tasks in the Workflow may be automatically triggered based on events.

02595: Cloud provider Agnostic: Open source technologies such as Apache Airflow, Apache Spark and Postgresql, and/or the like may be leveraged.

02606: Performance Optimization: Computation performance may be optimized by using network-optimized, memory-optimized and/or compute-optimized cloud instances based on the nature of the computation. Multiple jobs may be scheduled to single or multiple clusters.

02617: Cost Optimization: Inexpensive commodity-grade virtual servers may be provisioned dynamically leveraging inexpensive Spot Instances or Reserved Instances.

0262An exemplary WDL that orchestrates the workflow and the dependencies may be implemented as follows:

0000<tables id="TABLE-US-00020" num="00020"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="336pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>default:</entry></row><row><entry /><entry> owner: ‘atim-de’</entry></row><row><entry /><entry>dag:</entry></row><row><entry /><entry> dag_id: atim-pg-prod</entry></row><row><entry /><entry> tasks:</entry></row><row><entry /><entry>  create_cluster:</entry></row><row><entry /><entry>   operator: PythonOperator</entry></row><row><entry /><entry>   python_callable: create_emr</entry></row><row><entry /><entry>   op_kwargs: {‘num_core_nodes’: 28}</entry></row><row><entry /><entry>  wait_for_cluster_completion:</entry></row><row><entry /><entry>   operator: PythonOperator</entry></row><row><entry /><entry>   python_callable: wait_for_completion</entry></row><row><entry /><entry>  terminate_cluster:</entry></row><row><entry /><entry>   operator: PythonOperator</entry></row><row><entry /><entry>   python_callable: terminate_emr</entry></row><row><entry /><entry>  bond_am:</entry></row><row><entry /><entry>   operator: PythonOperator</entry></row><row><entry /><entry>   python_callable: run_spark_job</entry></row><row><entry /><entry>   op_kwargs: {‘file’: ‘s3://codebase/bond_am.jar’, ‘conf’:</entry></row><row><entry /><entry> ‘s3://codebase/bond_am/app.conf’, ‘className’: ‘com.atim.data.ETLHashDirect’}</entry></row><row><entry /><entry>  fund_am:</entry></row><row><entry /><entry>   operator: PythonOperator</entry></row><row><entry /><entry>   python_callable: run_spark_job</entry></row><row><entry /><entry>   op_kwargs: {‘file’: ‘s3://codebase/fund_am.jar’, ‘conf’:</entry></row><row><entry /><entry> ‘s3://codebase/fund_am/app.conf’, ‘className’: ‘com.atim.data.ETLHashDirect’}</entry></row><row><entry /><entry>  bond_expo:</entry></row><row><entry /><entry>   operator: PythonOperator</entry></row><row><entry /><entry>   python_callable: run_spark_job</entry></row><row><entry /><entry>   op_kwargs: {‘file’: ‘s3://codebase/bond_expo.jar’, ‘conf’:</entry></row><row><entry /><entry> ‘s3://codebase/bond_expo/app.conf’, ‘className’: ‘com.atim.data.ETLHashDirect’}</entry></row><row><entry /><entry>  fund_expo:</entry></row><row><entry /><entry>   operator: PythonOperator</entry></row><row><entry /><entry>   python_callable: run_spark_job</entry></row><row><entry /><entry>   op_kwargs: {‘file’: ‘s3://codebase/fund_expo.jar’, ‘conf’:</entry></row><row><entry /><entry> ‘s3://codebase/fund_expo/app.conf’, ‘className’: ‘com.atim.data.ETLHashDirect’}</entry></row><row><entry /><entry>  merge_am:</entry></row><row><entry /><entry>   operator: PythonOperator</entry></row><row><entry /><entry>   python_callable: run_spark_job</entry></row><row><entry /><entry>   op_kwargs: {‘file’: ‘s3://codebase/merge_am.jar’, ‘conf’:</entry></row><row><entry /><entry> ‘s3://codebase/merge_am/app.conf’, ‘className’: ‘com.atim.data.S3MergeMapAm’}</entry></row><row><entry /><entry>  merge_expo:</entry></row><row><entry /><entry>   operator: PythonOperator</entry></row><row><entry /><entry>   python_callable: run_spark_job</entry></row><row><entry /><entry>   op_kwargs: {‘file’: ‘s3://codebase/merge_expo.jar’, ‘conf’:</entry></row><row><entry /><entry> ‘s3://codebase/merge_expo/app.conf’, ‘className’: ‘com.atim.data.S3MergeMap’}</entry></row><row><entry /><entry>  asim3M_DL_CMA:</entry></row><row><entry /><entry>   operator: PythonOperator</entry></row><row><entry /><entry>   python_callable: run_spark_job</entry></row><row><entry /><entry>   op_kwargs: {‘file’: ‘s3://codebase/postgres/main.py’, ‘pyFiles’:</entry></row><row><entry /><entry> [“s3://codebase/postgres/asim.zip”], ‘args’: [‘atimProdConfig_DL_3M.yml’]}</entry></row><row><entry /><entry>  asim6M_DL_CMA:</entry></row><row><entry /><entry>   operator: PythonOperator</entry></row><row><entry /><entry>   python_callable: run_spark_job</entry></row><row><entry /><entry>   op_kwargs: {‘file’: ‘s3://codebase/postgres/main.py’, ‘pyFiles’:</entry></row><row><entry /><entry> [“s3://codebase/postgres/asim.zip”], ‘args’: [‘atimProdConfig_DL_6M.yml’]}</entry></row><row><entry /><entry>  asim1Y_DL_CMA:</entry></row><row><entry /><entry>   operator: PythonOperator</entry></row><row><entry /><entry>   python_callable: run_spark_job</entry></row><row><entry /><entry>   op_kwargs: {‘file’: ‘s3://codebase/postgres/main.py’, ‘pyFiles’:</entry></row><row><entry /><entry> [“s3://codebase/postgres/asim.zip”], ‘args’: [‘atimProdConfig_DL_1Y.yml’]}</entry></row><row><entry /><entry>  asim1Y_DL_NONCMA:</entry></row><row><entry /><entry>   operator: PythonOperator</entry></row><row><entry /><entry>   python_callable: run_spark_job</entry></row><row><entry /><entry>   op_kwargs: {‘file’: ‘s3://codebase/postgres/main.py’, ‘pyFiles’:</entry></row><row><entry /><entry> [“s3://codebase/postgres/asim.zip”], ‘args’: [‘atimProdConfig_DL_1Y_NonCMA.yml’]}</entry></row><row><entry /><entry>  asim3M_MV_CMA:</entry></row><row><entry /><entry>   operator: PythonOperator</entry></row><row><entry /><entry>   python_callable: run_spark_job</entry></row><row><entry /><entry>   op_kwargs: {‘file’: ‘s3://codebase/postgres/main.py’, ‘pyFiles’:</entry></row><row><entry /><entry> [“s3://codebase/postgres/asim.zip”], ‘args’: [‘atimProdConfig_MV_3M.yml’]}</entry></row><row><entry /><entry>  asim6M_MV_CMA:</entry></row><row><entry /><entry>   operator: PythonOperator</entry></row><row><entry /><entry>   python_callable: run_spark_job</entry></row><row><entry /><entry>   op_kwargs: {‘file’: ‘s3://codebase/postgres/main.py’, ‘pyFiles’:</entry></row><row><entry /><entry> [“s3://codebase/postgres/asim.zip”], ‘args’: [‘atimProdConfig_MV_6M.yml’]}</entry></row><row><entry /><entry>  asim1Y_MV_CMA:</entry></row><row><entry /><entry>   operator: PythonOperator</entry></row><row><entry /><entry>   python_callable: run_spark_job</entry></row><row><entry /><entry>   op_kwargs: {‘file’: ‘s3://codebase/postgres/main.py’, ‘pyFiles’:</entry></row><row><entry /><entry> [“s3://codebase/postgres/asim.zip”], ‘args’: [‘atimProdConfig_MV_1Y.yml’]}</entry></row><row><entry /><entry>  db_data_maintenance:</entry></row><row><entry /><entry>   operator: BashOperator</entry></row><row><entry /><entry>   bash_command: ‘query’</entry></row><row><entry /><entry>  push_asset_to_snowflake:</entry></row><row><entry /><entry>   operator: BashOperator</entry></row><row><entry /><entry>   bash_command: “snowflake_asset.sh'”</entry></row><row><entry /><entry>  push_assetsim_to_snowflake:</entry></row><row><entry /><entry>   operator: BashOperator</entry></row><row><entry /><entry>   bash_command: “snowflake_assetsim.sh”</entry></row><row><entry /><entry> dependancies:</entry></row><row><entry /><entry>  - create_cluster >> wait_for_cluster_completion</entry></row><row><entry /><entry>  - wait_for_cluster_completion >> bond_expo</entry></row><row><entry /><entry>  - bond_expo >> fund_expo, bond_am, fund_am</entry></row><row><entry /><entry>  - bond_am, fund_am >> merge_am</entry></row><row><entry /><entry>  - bond_expo, fund_expo >> merge_expo</entry></row><row><entry /><entry>  - merge_am >> merge_expo</entry></row><row><entry /><entry>  - merge_expo >> asim3M_DL_CMA, asim6M_DL_CMA, asim1Y_DL_CMA, asim1Y_DL_NONCMA,</entry></row><row><entry /><entry>asim3M_MV_CMA, asim6M_MV_CMA, asim1Y_MV_CMA</entry></row><row><entry /><entry>  - asim3M_DL_CMA, asim6M_DL_CMA, asim1Y_DL_CMA, asim1Y_DL_NONCMA, asim3M_MV_CMA,</entry></row><row><entry /><entry>asim6M_MV_CMA, asim1Y_MV_CMA >> terminate_cluster</entry></row><row><entry /><entry>  - terminate_cluster >> db_data_maintenance</entry></row><row><entry /><entry>  - terminate_cluster >> push_asset_to_snowflake</entry></row><row><entry /><entry>  - push_asset_to_snowflake >> push_assetsim_to_snowflake</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0263The visual view of the above workflow is illustrated at <b>702</b> in <figref idref="DRAWINGS">FIG. 7C</figref>.

0264Exemplary pseudo code that distributes the asset simulation across provisioned clusters of nodes is shown below. Exposure data in ‘expo’ and factor simulation data (encapsulated in the curried function fsim_func) may be broadcasted to the worker nodes for distributed computation.

0000<tables id="TABLE-US-00021" num="00021"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry> </entry><entry>Expo data are read and partitioned by asset_id:</entry></row><row><entry /><entry /><entry>expo_tall_sdf = self.sqlContext.read.jdbc(</entry></row><row><entry /><entry /><entry>  url=self.jdbc_conn_str,</entry></row><row><entry /><entry /><entry>  table=fexpo_sql,</entry></row><row><entry /><entry /><entry>  properties=conn_props</entry></row><row><entry /><entry /><entry>)</entry></row><row><entry /><entry /><entry>partition_meta = {</entry></row><row><entry /><entry /><entry>  ‘numPartitions’: str(self.read_partitions),</entry></row><row><entry /><entry /><entry>  ‘partitionColumn’: ‘ asset_id’,</entry></row><row><entry /><entry /><entry>  ‘lowerBound’: ‘0’,</entry></row><row><entry /><entry /><entry>  ‘upperBound’: str(self.select_fexpo_count(pricing_dt))</entry></row><row><entry /><entry /><entry>}</entry></row><row><entry /><entry /><entry>expo.rdd.map(fsim_func)</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0265Calculations may be executed concurrently on the worker nodes using pseudo code such as shown below. Factor Sims may be broadcasted to the worker nodes.

0000<tables id="TABLE-US-00022" num="00022"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="259pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>def calculate_inst(x):</entry></row><row><entry /><entry>  ″″″</entry></row><row><entry /><entry>  Performs dot product between row of Factor Exposer RDD (x)</entry></row><row><entry /><entry>  and Factor Sim matrix return as list of lists.</entry></row><row><entry /><entry>  ″″″</entry></row><row><entry /><entry>  sy = asset_ref_dict.get(str(x.asset_id), { }).get(“static_yield”, Decimal(‘0.0’))</entry></row><row><entry /><entry>  # month to mature</entry></row><row><entry /><entry>  mon2mature = asset_ref_dict.get(str(x.asset_id), { }).get(“month_to_mature”, { })</entry></row><row><entry /><entry>  bias_coef = bias_coef_with_month2mature(mon2mature, horizon)</entry></row><row><entry /><entry>  # Dot product and set datatype as float</entry></row><row><entry /><entry>  fsim = fsim_vals.astype(float)</entry></row><row><entry /><entry>  fexpo = np.array(x)[fexpo_fctr_idx].astype(float)</entry></row><row><entry /><entry>  return_arry = fsim.dot(fexpo)</entry></row><row><entry /><entry>  # clip return via option price upper and lower</entry></row><row><entry /><entry>  p_lower = asset_ref_dict.get(str(x.asset_id), { }).get(“price_lower”, { })</entry></row><row><entry /><entry>  p_upper = asset_ref_dict.get(str(x.asset_id), { }).get(“price_upper”, { })</entry></row><row><entry /><entry>  return_clip = clip_lower_and_upper(p_lower, p_upper, return_arry)</entry></row><row><entry /><entry>  # add carry</entry></row><row><entry /><entry>  return_clip_plus_carry = np.array(return_clip).astype(float) + float(bias_coef) *</entry></row><row><entry /><entry>float(sy)</entry></row><row><entry /><entry>  #CVaR calculation</entry></row><row><entry /><entry>  cvar_minus =</entry></row><row><entry /><entry>np.mean(np.sort(return_clip_plus_carry)[:int(len(return_clip_plus_carry) *</entry></row><row><entry /><entry>cvar_percentile * 0.01)])</entry></row><row><entry /><entry>  return_int = array2int(return_clip_plus_carry)</entry></row><row><entry /><entry>  return [x.asset_id, x.pricing_dt, sim_id, return_int, float(cvar_minus)]</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0266The generated asset simulation data may be populated into RDMS Postgresql and Enterprise Snowflake Data Lake in a wide format for optimal performance. The wide format is illustrated at <b>706</b> in <figref idref="DRAWINGS">FIG. 7C</figref>.

0267The wide format may be turned into a tall format for reporting and analysis as follows: <ul id="ul0013" list-style="none"><li id="ul0013-0001" num="0000"><ul id="ul0014" list-style="none"><li id="ul0014-0001" num="0268">SELECT asset_id, sim_id, generate_series(0,7449) market_id, unnest(returns) as returns</li><li id="ul0014-0002" num="0269">FROM prod.asset_sim_w</li><li id="ul0014-0003" num="0270">WHERE asset_id=2012082100000122 and sim_id=34 and pricing_dt=‘2020-06-05’</li><li id="ul0014-0004" num="0271">ORDER BY 1, 2, 3;</li></ul></li></ul>

0272The tall format is illustrated at <b>710</b> in <figref idref="DRAWINGS">FIG. 7C</figref>. In this figure, market scenario identifier field scenario identifier is referred to as market id.

0273<figref idref="DRAWINGS">FIG. 8</figref> shows a datagraph illustrating data flow(s) for the MLPO. In <figref idref="DRAWINGS">FIG. 8</figref>, a user client <b>804</b> (e.g., of a user) may send a portfolio construction request <b>821</b> to a MLPO server <b>806</b> to facilitate creating an optimized portfolio. For example, the user client may be a desktop, a laptop, a tablet, a smartphone, a smartwatch, and/or the like that is executing a client application. In one implementation, the portfolio construction request may include data such as a request identifier, optimization parameters (e.g., investable universe, time period, total investment amount, conditional value at risk (CVaR) percentile, CVaR threshold, whether to optimize relative to a benchmark portfolio, benchmark portfolio weights, integer quantity constraint, number of positions threshold (e.g., lower bound), position market value weight threshold (e.g., upper bound), etc.), and/or the like. In one embodiment, the user client may provide the following example portfolio construction request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00023" num="00023"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="280pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /portfolio_construction_request.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><portfolio_construction_request></entry></row><row><entry /><entry>  <request_identifier>ID_request_11</request_identifier></entry></row><row><entry /><entry>  <optimization_parameters></entry></row><row><entry /><entry>    <investable_universe>Securities in S&P 500</investable_universe></entry></row><row><entry /><entry>    <time_period>6 months</time_period></entry></row><row><entry /><entry>    <total_amount>$1,000,000</total_amount></entry></row><row><entry /><entry>    <CVAR_percentile>5%</CVAR_percentile></entry></row><row><entry /><entry>    <CVAR_threshold>10%</CVAR_threshold></entry></row><row><entry /><entry>    <is_relative_to_benchmark_portfolio>FALSE</is_relative_to_benchmark_portfolio></entry></row><row><entry /><entry>    <integer_quantity_constraint>TRUE</integer_quantity_constraint></entry></row><row><entry /><entry>    <number_of_positions_threshold>at least 30</number_of_positions_threshold></entry></row><row><entry /><entry>    <position_weight_threshold>10%</position_weight_threshold></entry></row><row><entry /><entry>  </optimization_parameters></entry></row><row><entry /><entry></portfolio_construction_request></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0274The MLPO server <b>806</b> may send an expected returns retrieve request <b>825</b> to a repository <b>810</b> to facilitate retrieving expected returns for securities in the portfolio universe for simulated scenarios (e.g., filtered) corresponding to the specified time period. In one implementation, the expected returns retrieve request may include data such as a request identifier, expected returns to retrieve specification, and/or the like. In one embodiment, the MLPO server may provide the following example expected returns retrieve request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00024" num="00024"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /expected_returns_retrieve_request.php HTTP/1.1</entry></row><row><entry>Host: www.server.com</entry></row><row><entry>Content-Type: Application/XML</entry></row><row><entry>Content-Length: 667</entry></row><row><entry></entry></row><row><entry><expected_returns_retrieve_request></entry></row><row><entry>  <request_identifier>ID_request_12</request_identifier></entry></row><row><entry>  <expected_returns_specification></entry></row><row><entry>    <simulation_identifier>ID_sim_1</simulation_identifier></entry></row><row><entry>    <scenario></entry></row><row><entry>      <scenario_identifier>ID_scenario_1</scenario_identifier></entry></row><row><entry>      <securities>MSFT, AAPL, ...</securities></entry></row><row><entry>    </scenario></entry></row><row><entry>    <scenario></entry></row><row><entry>      <scenario_identifier>ID_scenario_2</scenario_identifier></entry></row><row><entry>      <securities>MSFT, AAPL, ...</securities></entry></row><row><entry>    </scenario></entry></row><row><entry>    ...</entry></row><row><entry>  </expected_returns_specification></entry></row><row><entry></expected_returns_retrieve_request></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0275The repository <b>810</b> may send an expected returns retrieve response <b>829</b> to the MLPO server <b>806</b> with the requested expected returns data. In one implementation, the expected returns retrieve response may include data such as a response identifier, the requested expected returns data, and/or the like. In one embodiment, the repository may provide the following example expected returns retrieve response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00025" num="00025"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /expected_returns_retrieve_response.php HTTP/1.1</entry></row><row><entry>Host: www.server.com</entry></row><row><entry>Content-Type: Application/XML</entry></row><row><entry>Content-Length: 667</entry></row><row><entry></entry></row><row><entry><expected_returns_retrieve_response></entry></row><row><entry>  <response_identifier>ID_response_12</response_identifier></entry></row><row><entry>  <expected_returns></entry></row><row><entry>    <scenario></entry></row><row><entry>      <scenario_identifier>ID_scenario_1</scenario_identifier></entry></row><row><entry>      <security></entry></row><row><entry>        <security_identifier>MSFT</security_identifier></entry></row><row><entry>        <expected_return>10%</expected_return></entry></row><row><entry>      </security></entry></row><row><entry>      <security></entry></row><row><entry>        <security_identifier>AAPL</security_identifier></entry></row><row><entry>        <expected_return>12%</expected_return></entry></row><row><entry>      </security></entry></row><row><entry>      ...</entry></row><row><entry>    </scenario></entry></row><row><entry>    <scenario></entry></row><row><entry>      <scenario_identifier>ID_scenario_2</scenario_identifier></entry></row><row><entry>      <security></entry></row><row><entry>        <security_identifier>MSFT</security_identifier></entry></row><row><entry>        <expected_return>15%</expected_return></entry></row><row><entry>      </security></entry></row><row><entry>      <security></entry></row><row><entry>        <security_identifier>AAPL</security_identifier></entry></row><row><entry>        <expected_return>13%</expected_return></entry></row><row><entry>      </security></entry></row><row><entry>      ...</entry></row><row><entry>    </scenario></entry></row><row><entry>    ...</entry></row><row><entry>  </expected_returns></entry></row><row><entry></expected_returns_retrieve_response></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0276A portfolio constructing (PC) component <b>833</b> may utilize data provided in the portfolio construction request and/or the expected returns retrieve response and/or via filters to determine and/or execute a set of tradeable buy and/or sell transactions to construct an optimized portfolio. See <figref idref="DRAWINGS">FIG. 9</figref> for additional details regarding the PC component.

0277The MLPO server <b>806</b> may send an order execution request <b>837</b> to an exchange server <b>808</b> to facilitate executing a tradeable buy and/or sell transaction used to construct the optimized portfolio. In one implementation, the order execution request may include data such as a request identifier, order details, and/or the like. In one embodiment, the MLPO server may provide the following example order execution request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00026" num="00026"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry> </entry><entry>POST /order_execution_request.php HTTP/1.1</entry></row><row><entry /><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry /><entry></entry></row><row><entry /><entry /><entry><order_execution_request></entry></row><row><entry /><entry /><entry>  <request_identifier>ID_request_13</request_identifier></entry></row><row><entry /><entry /><entry>  <order_details></entry></row><row><entry /><entry /><entry>    <security_identifier>AAPL</security_identifier></entry></row><row><entry /><entry /><entry>    <action>BUY</action></entry></row><row><entry /><entry /><entry>    <quantity>1000 shares</quantity></entry></row><row><entry /><entry /><entry>  </order_details></entry></row><row><entry /><entry /><entry></order_execution_request></entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0278The exchange server <b>808</b> may send an order execution response <b>841</b> to the MLPO server <b>806</b> to confirm that the tradeable buy and/or sell transaction was executed successfully. In one implementation, the order execution response may include data such as a response identifier, a status, and/or the like. In one embodiment, the exchange server may provide the following example order execution response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00027" num="00027"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /order_execution_response.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><order_execution_response></entry></row><row><entry /><entry>  <response_identifier>ID_response_13</response_identifier></entry></row><row><entry /><entry>  <status>OK</status></entry></row><row><entry /><entry></order_execution_response></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0279The MLPO server <b>806</b> may send a portfolio construction response <b>845</b> to the user client <b>804</b> to inform the user that an optimized portfolio was constructed successfully. In one implementation, the portfolio construction response may include data such as a response identifier, a status, and/or the like. In one embodiment, the MLPO server may provide the following example portfolio construction response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00028" num="00028"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /portfolio_construction_response.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><portfolio_construction_response></entry></row><row><entry /><entry>  <response_identifier>ID_response_11</response_identifier></entry></row><row><entry /><entry>  <status>OK</status></entry></row><row><entry /><entry></portfolio_construction_response></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0280<figref idref="DRAWINGS">FIG. 9</figref> shows a logic flow illustrating embodiments of a portfolio constructing (PC) component for the MLPO. In <figref idref="DRAWINGS">FIG. 9</figref>, a portfolio construction request may be obtained at <b>901</b>. For example, the portfolio construction request may be obtained as a result of a user requesting creation of an optimized portfolio.

0281Optimization parameters for constructing the optimized portfolio may be determined at <b>905</b>. For example, the optimization parameters may include a universe of investment securities, investment amount, Conditional Value at Risk (CVaR) percentile, CVaR threshold, an investment time period, whether to optimize relative to a benchmark portfolio, benchmark portfolio weights, integer quantity constraint, and/or the like. In one implementation, the portfolio construction request may be parsed (e.g., using PHP commands) to determine the optimization parameters (e.g., based on the value of the optimization_parameters field). For example, the optimization parameters may be specified as follows:

0282Arguments <ul id="ul0015" list-style="none"><li id="ul0015-0001" num="0000"><ul id="ul0016" list-style="none"><li id="ul0016-0001" num="0283">1. market_value=1e7 <ul id="ul0017" list-style="none"><li id="ul0017-0001" num="0284">Total amount of cash (e.g., in US dollars) provided for investment. Default 1e7. Note that (the holding portfolio market value)+(cash residue)=total_dollar_amount.</li></ul></li><li id="ul0016-0002" num="0285">2. cvar_percentile=5 <ul id="ul0018" list-style="none"><li id="ul0018-0001" num="0286">The percentage of worst outcome. Default 5.</li></ul></li><li id="ul0016-0003" num="0287">3. cvar_threshold=−450 <ul id="ul0019" list-style="none"><li id="ul0019-0001" num="0288">The expected loss at the cvar_percentile worst outcome. Default −450.</li></ul></li><li id="ul0016-0004" num="0289">4. investable_universe <ul id="ul0020" list-style="none"><li id="ul0020-0001" num="0290">A list of the assets that could be allocated.</li></ul></li><li id="ul0016-0005" num="0291">5. asset_sim <ul id="ul0021" list-style="none"><li id="ul0021-0001" num="0292">A 2d list, each row is a simulated scenario, and each column is an asset. The order of the columns should be the same as the order in the investable_universe.</li></ul></li><li id="ul0016-0006" num="0293">6. asset_return <ul id="ul0022" list-style="none"><li id="ul0022-0001" num="0294">A list of expected yields of the assets, with the same order of the investable_universe.</li></ul></li><li id="ul0016-0007" num="0295">7. asset_price <ul id="ul0023" list-style="none"><li id="ul0023-0001" num="0296">A list of price (e.g., in US dollar) of the assets with the same order of the investable_universe.</li></ul></li><li id="ul0016-0008" num="0297">8. asset min denom <ul id="ul0024" list-style="none"><li id="ul0024-0001" num="0298">A list of the minimum par-amount to purchase for each asset, following the same order in the investable_universe. Rescaled to quantity by dividing 100 inside the optimization solver.</li></ul></li><li id="ul0016-0009" num="0299">9. asset_min_incrmnt <ul id="ul0025" list-style="none"><li id="ul0025-0001" num="0300">A list of the par-amount increment to purchase for each asset, following the same order in the investable_universe. Rescaled to quantity by dividing 100 inside the optimization solver.</li></ul></li></ul></li></ul>

0301Additional Optional Arguments <ul id="ul0026" list-style="none"><li id="ul0026-0001" num="0000"><ul id="ul0027" list-style="none"><li id="ul0027-0001" num="0302">10. pct_univ_allocated=0.8 when number of assets &lt;=10 else 0.6 <ul id="ul0028" list-style="none"><li id="ul0028-0001" num="0303">The fraction of the allocated assets in all the assets. Default 0.8 when number of assets &lt;=10, else 0.6.</li></ul></li><li id="ul0027-0002" num="0304">11. allocation_ub=0.8*market_value/asset_price <ul id="ul0029" list-style="none"><li id="ul0029-0001" num="0305">A 1d list of the upper bound of allocated quantity of each asset with the same order of the investable_universe. Default 0.8*market_value/asset_price.</li></ul></li><li id="ul0027-0003" num="0306">12. allocation_lb=1e-3*market_value/asset_price <ul id="ul0030" list-style="none"><li id="ul0030-0001" num="0307">A 1d list of the lower bound of allocated quantity of the allocated assets with the same order of the investable_universe. Default 1e-3*market_value/asset_price.</li></ul></li><li id="ul0027-0004" num="0308">13. available_2_trade=market_value/asset_price <ul id="ul0031" list-style="none"><li id="ul0031-0001" num="0309">A 1d list of the maximum available quantity of the assets with the same order of the investable_universe. Default market_value/asset_price.</li></ul></li><li id="ul0027-0005" num="0310">14. is_allocate_neg_rtn=True <ul id="ul0032" list-style="none"><li id="ul0032-0001" num="0311">Boolean. If True, assign zero weights to assets with negative expected return (in arg #6). Default True.</li></ul></li><li id="ul0027-0006" num="0312">15. max_exe_time=120 <ul id="ul0033" list-style="none"><li id="ul0033-0001" num="0313">The maximum execution time in seconds. If no allocation solution found within the max_exe_time (e.g., default 2 mins), the optimization solver returns 0 for the assets.</li></ul></li><li id="ul0027-0007" num="0314">16. is_relative=False <ul id="ul0034" list-style="none"><li id="ul0034-0001" num="0315">Boolean. If True and tracking_error (arg #17) is not None and asset_quant_base (arg #18) is not None, relative algorithm may be triggered. Default False.</li></ul></li><li id="ul0027-0008" num="0316">17. bmk_weight=None <ul id="ul0035" list-style="none"><li id="ul0035-0001" num="0317">A 1d list of the allocation weights of the benchmark portfolio. Default is None. Note that when arg #16 is True, and arg #17 is not None, and arg #18 is not None, the relative algorithm may be triggered.</li></ul></li><li id="ul0027-0009" num="0318">18. bmk sim=None <ul id="ul0036" list-style="none"><li id="ul0036-0001" num="0319">A 2d list of the simulation scenarios of the assets in the benchmark portfolio. Each row is a scenario, and each column is an asset. Rows follows the order of that in asset_sim(arg #5), and columns follow the order of that in bmk_weight(arg #17). Default None. Note that when arg #16 is True, and arg #17 is not None, and arg #18 is not None, the relative algorithm may be triggered.</li></ul></li><li id="ul0027-0010" num="0320">19. convergence_threshold=1e-3 <ul id="ul0037" list-style="none"><li id="ul0037-0001" num="0321">The minimum delta of the objective function in the branch-and-cut searching algorithm.</li></ul></li></ul></li></ul>

0322Market scenarios to utilize for constructing the optimized portfolio may be determined at <b>907</b>. In one embodiment, the market scenarios to utilize may be determined based on the simulation model (e.g., for a specified pricing date) and/or time period length selected by the user. For example, the user may choose to utilize simulated market scenarios generated using a deep learning neural network simulation model (e.g., for the specified pricing date) for a 3 month, 6 month or 1 year investment time period (e.g., as discussed with regard to <figref idref="DRAWINGS">FIGS. 2A-B</figref>), or to utilize simulated market scenarios generated using a multivariate mixture simulation model (e.g., for the specified pricing date) for a 3 month, 6 month or 1 year investment time period (e.g., as discussed with regard to <figref idref="DRAWINGS">FIG. 4</figref>). In another embodiment, the market scenarios to utilize may be determined based on filters applied to simulated market scenarios. For example, the user may choose to filter simulated market scenarios based on specified ranges of allowable values for specified customized market factors (e.g., as discussed with regard to <figref idref="DRAWINGS">FIG. 21</figref>), and/or based on specified business cycle settings (e.g., as discussed with regard to <figref idref="DRAWINGS">FIG. 27</figref>).

0323Expected returns of securities in the universe of investment securities for the determined market scenarios to utilize may be retrieved from a database at <b>909</b>. For example, if the user wishes to construct an optimized portfolio for a 6 month investment time period using a deep learning neural network simulation model, expected returns of securities in the universe of investment securities for simulated market scenarios generated by the deep learning neural network simulation model for 6 month rolling window periods (e.g., for the 60,000 simulated scenarios) may be retrieved. In another example, if the user wishes to construct an optimized portfolio conditional on VIX rising more than 400 bps over a 3 month horizon, expected returns of securities in the universe of investment securities for filtered simulated market scenarios having VIX change greater than 400 bps over the 3 month horizon may be retrieved. In another example, if the user wishes to construct an optimized portfolio conditional on having Late business cycle over a 3 month horizon, expected returns of securities in the universe of investment securities for filtered simulated market scenarios associated with Late business cycle over the 3 month horizon may be retrieved (e.g., alternatively, weighted expected security returns may be utilized when multiple business cycles with associated business cycle weights are utilized). In one implementation, the expected returns may be retrieved via an expected returns retrieve request.

0324A determination may be made at <b>913</b> whether the optimized portfolio should be optimized relative to a benchmark portfolio. If so, starting securities weights may be initialized to benchmark portfolio weights at <b>917</b>.

0325Portfolio securities weights may be optimized in accordance with the optimization parameters at <b>921</b>. In one implementation, the PC component may perform a convex optimization to find a mixed integer linear programming (MILP) portfolio solution that ensures that tradable buy and sell transactions can be generated. The optimization objective may be set to maximize the expected portfolio return. In various embodiments, a variety of approaches may be used to perform the optimization. For example, one approach is to use stochastic optimization process to search for suboptimal weights of the asset for a fixed amount of time and/or iterations and select the solution with allowable CVaR and maximum returns. For example, a second approach is to use MILP to solve for the global optimum solution and use linear relaxation of CVaR constraint with the weights result in tradability for each security respecting the trading rules such as minimum denomination and minimum increments. For example, a third approach is to use linear relaxation of CVaR constraint, but use a binary branch and cut modified MILP implementation (BILP), where non-integer solutions are allowed for those bigger than the minimum denomination values. For example, a fourth approach is to use linear relaxation of CVaR constrain and conduct a direct linear programing optimization, allowing the allocated weights to be a non-integer (decimal) solution and rounding the trade quantity to the nearable tradable amount. In one embodiment, the optimization implementation may be solver independent. In various implementations, multiple linear programming, quadratic programming and mixed integer programming solvers may be supported, including both commercial solvers and open-source solvers (e.g., CVXOPT(SIMPLEX), GUROBI, scypy.optimize(interior point)). For example, the user may select which solvers to use from a portfolio construction graphical user interface.

0326Tradeable buy and/or sell transactions to execute may be determined at <b>925</b>. In one embodiment, the tradeable buy and/or sell transactions are generated to make weights of securities in the optimized portfolio correspond to the determined optimized portfolio securities weights. In one implementation, the optimized portfolio may be a newly created portfolio. For example, tradeable buy transactions may be determined to obtain each security with a non-zero weight in accordance with its optimized portfolio weight. In another implementation, the optimized portfolio may be an existing portfolio (e.g., the benchmark portfolio). For example, tradeable buy and/or sell transactions may be determined to increase and/or reduce weights of securities in the existing portfolio to make the weight of each security correspond to its optimized portfolio weight.

0327The tradeable buy and/or sell transactions may be executed at <b>929</b>. In one implementation, orders corresponding the tradeable buy and/or sell transactions may be sent to an exchange server via one or more order execution requests.

0328<figref idref="DRAWINGS">FIG. 10</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 10</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for constructing an optimized portfolio is illustrated. Screen <b>1001</b> shows that a user may utilize a securities universe widget <b>1005</b> to specify a universe of investment securities. For example, the user may specify a set of equities, bonds, indexes, portfolio holdings, and/or the like. The user may utilize a benchmark widget <b>1007</b> to specify a benchmark portfolio relative to which the optimized portfolio should be optimized. The user may utilize a simulation model widget <b>1010</b> to specify a simulation model that should be utilized. The user may utilize a pricing date widget <b>1015</b> to specify a pricing date associated with the simulation model. The user may utilize a portfolio market value widget <b>1020</b> to specify an investment amount.

0329<figref idref="DRAWINGS">FIG. 11</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 11</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for constructing an optimized portfolio is illustrated. Screen <b>1101</b> shows that the user may utilize a CVaR percentile widget <b>1105</b> to specify the percentile (e.g., 5%) of the worst return outcomes. The user may utilize a CVaR threshold widget <b>1110</b> to specify the expected loss (e.g., 7%) at the worst CVaR percentile outcomes (e.g., the expected loss based on a weighted average (e.g., weighted based on occurrence probability) of the worst 5% of return outcomes). The user may utilize an investment time period widget <b>1115</b> to specify the investment time frame (e.g., over a 3 month time period). The user may utilize optimization objective widgets <b>1120</b>, <b>1125</b> to specify the optimization objective (e.g., maximize total return). Other portfolio construction constraints that may be specified by the user may include: maximum percentage market value (PMV) per allocated asset, minimum number of allocated assets per portfolio, and/or the like. The user may utilize an optimize widget <b>1130</b> to initiate the creation of the optimized portfolio.

0330<figref idref="DRAWINGS">FIG. 12</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 12</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for constructing an optimized portfolio is illustrated. Screen <b>1201</b> shows exemplary values that the user may select using the CVaR percentile widget <b>1205</b>, the CVaR threshold widget <b>1210</b>, and the investment time period widget <b>1215</b>. The user may utilize an expected return widget <b>1220</b> to view the expected return (e.g., −6.61%) of the optimized portfolio, the expected return (e.g., 0.81%) of the original portfolio before changes to the portfolio securities weights, and the difference in the expected return (e.g., −7.43%) between the two portfolios. The user may utilize a drawdown widget <b>1225</b> to view the expected loss (e.g., −7.00%) at the worst CVaR percentile outcomes for the optimized portfolio, the expected loss (e.g., −8.35%) at the worst CVaR percentile outcomes for the original portfolio before changes to the portfolio securities weights, and the difference in the expected loss at the worst CVaR percentile outcomes (e.g., 1.35) between the two portfolios. The user may utilize a return volatility widget <b>1230</b> to view the return volatility (e.g., 3.62%) of the optimized portfolio, the return volatility (e.g., 3.80%) of the original portfolio before changes to the portfolio securities weights, and the difference in the return volatility (e.g., −0.19%) between the two portfolios. The user may utilize a returns distribution widget <b>1235</b> to view how the returns distribution of the optimized portfolio compares to the returns distribution of the original portfolio before changes to the portfolio securities weights. The user may utilize a portfolio securities weights widget <b>1240</b> to view and/or modify portfolio securities weights of individual portfolio securities of the optimized portfolio. The user may utilize a portfolio securities returns widget <b>1245</b> to view expected returns of individual portfolio securities of the optimized portfolio. The user may utilize an execute widget <b>1255</b> to initiate the execution of tradeable buy and/or sell transactions utilized to create the optimized portfolio.

0331<figref idref="DRAWINGS">FIG. 13</figref> shows a datagraph illustrating data flow(s) for the MLPO. In <figref idref="DRAWINGS">FIG. 13</figref>, dashed lines indicate data flow elements that may be more likely to be optional. In <figref idref="DRAWINGS">FIG. 13</figref>, a user client <b>1304</b> (e.g., of a user) may send a predefined scenario construction request <b>1321</b> to a MLPO server <b>1306</b> to facilitate constructing a predefined scenario (e.g., a set of customized market factors used to generate a set of filtered simulated market scenarios). For example, the user client may be a desktop, a laptop, a tablet, a smartphone, a smartwatch, and/or the like that is executing a client application. In some alternative embodiments, the predefined scenario construction request may instead be sent by an administrative client <b>1302</b> (e.g., of an administrative user). In one implementation, the predefined scenario construction request may include data such as a request identifier, a user identifier, a predefined scenario identifier, a simulation model, a pricing date, and/or the like. In one embodiment, the user client may provide the following example predefined scenario construction request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00029" num="00029"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="266pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /predefined_scenario_construction_request.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><predefined_scenario_construction_request></entry></row><row><entry /><entry>  <request_identifier>ID_request_21</request_identifier></entry></row><row><entry /><entry>  <user_identifier>ID_user_1</user_identifier></entry></row><row><entry /><entry>  <predefined_scenario_identifier></entry></row><row><entry /><entry>    ID_predefined_scenario_1</entry></row><row><entry /><entry>  </predefined_scenario_identifier></entry></row><row><entry /><entry>  <simulation_model>ID_neural_network_simulation_model_1Y</simulation_model></entry></row><row><entry /><entry>  <pricing_date>2020-04-17</pricing_date></entry></row><row><entry /><entry></predefined_scenario_construction_request></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0332The MLPO server <b>1306</b> may send a scenario results retrieve request <b>1325</b> to a repository <b>1310</b> to facilitate retrieving simulated market scenarios associated with the specified simulation. In one implementation, the scenario results retrieve request may include data such as a request identifier, a simulation identifier (e.g., determined based on the specified pricing date and/or simulation model), a set of simulated market scenarios (e.g., filtered), and/or the like. In one embodiment, the MLPO server may provide the following example scenario results retrieve request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00030" num="00030"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /scenario_results_retrieve_request.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><scenario_results_retrieve_request></entry></row><row><entry /><entry>  <request_identifier>ID_request_22</request_identifier></entry></row><row><entry /><entry>  <simulation_identifier>ID_sim_1</simulation_identifier></entry></row><row><entry /><entry>  <scenario_identifiers>ALL</scenario_identifiers></entry></row><row><entry /><entry></scenario_results_retrieve_request></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0333The repository <b>1310</b> may send a scenario results retrieve response <b>1329</b> to the MLPO server <b>1306</b> with the requested simulated market scenarios data. In one implementation, the scenario results retrieve response may include data such as a response identifier, the requested simulated market scenarios data, and/or the like. In one embodiment, the repository may provide the following example scenario results retrieve response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00031" num="00031"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="280pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /scenario_results_retrieve_response.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><scenario_results_retrieve_response></entry></row><row><entry /><entry>  <response_identifier>ID_response_22</response_identifier></entry></row><row><entry /><entry>  <scenarios_data></entry></row><row><entry /><entry>    <scenario_data></entry></row><row><entry /><entry>      <scenario_identifier>ID_scenario_1</scenario_identifier></entry></row><row><entry /><entry>      <market_factor></entry></row><row><entry /><entry>        <market_factor_identifier>ID_interest_rate_5Y</market_factor_identifier></entry></row><row><entry /><entry>        <market_factor_change>25 basis points</market_factor_change></entry></row><row><entry /><entry>      </market_factor></entry></row><row><entry /><entry>      <market_factor></entry></row><row><entry /><entry>        <market_factor_identifier>ID_oil_price</market_factor_identifier></entry></row><row><entry /><entry>        <market_factor_change>$10</market_factor_change></entry></row><row><entry /><entry>      </market_factor></entry></row><row><entry /><entry>      ...</entry></row><row><entry /><entry>    </scenario_data></entry></row><row><entry /><entry>    <scenario_data></entry></row><row><entry /><entry>      <scenario_identifier>ID_scenario_2</scenario_identifier></entry></row><row><entry /><entry>      <market_factor></entry></row><row><entry /><entry>        <market_factor_identifier>ID_interest_rate_5Y</market_factor_identifier></entry></row><row><entry /><entry>        <market_factor_change>50 basis points</market_factor_change></entry></row><row><entry /><entry>      </market_factor></entry></row><row><entry /><entry>      <market_factor></entry></row><row><entry /><entry>        <market_factor_identifier>ID_oil_price</market_factor_identifier></entry></row><row><entry /><entry>        <market_factor_change>$15</market_factor_change></entry></row><row><entry /><entry>      </market_factor></entry></row><row><entry /><entry>      ...</entry></row><row><entry /><entry>    </scenario_data></entry></row><row><entry /><entry>    ...</entry></row><row><entry /><entry>  </scenarios_data></entry></row><row><entry /><entry></scenario_results_retrieve_response></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0334A predefined scenario constructing (PSC) component <b>1333</b> may utilize data provided in the predefined scenario construction request, data provided in the scenario results retrieve response, and/or data provided via scenario customization input to construct the predefined scenario. See <figref idref="DRAWINGS">FIGS. 14A-B</figref> for additional details regarding the PSC component.

0335The user client <b>1304</b> may send a scenario customization input <b>1337</b> to the MLPO server <b>1306</b> to specify a range of values for a customized market factor. In some alternative embodiments, the scenario customization input may instead be sent by the administrative client <b>1302</b>. In one implementation, the scenario customization input may include data such as a request identifier, a market factor identifier, a minimum range value, a maximum range value, and/or the like. In one embodiment, the user client may provide the following example scenario customization input, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00032" num="00032"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /scenario_customization_input.php HTTP/1.1</entry></row><row><entry>Host: www.server.com</entry></row><row><entry>Content-Type: Application/XML</entry></row><row><entry>Content-Length: 667</entry></row><row><entry></entry></row><row><entry><scenario_customization_input></entry></row><row><entry>  <request_identifier>ID_request_23</request_identifier></entry></row><row><entry>  <market_factor_identifier>ID_oil_price</market_factor_identifier></entry></row><row><entry>  <minimum_range_value>-49.00</minimum_range_value></entry></row><row><entry>  <maximum_range_value>19992.00</maximum_range_value></entry></row><row><entry></scenario_customization_input></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0336The MLPO server <b>1306</b> may send a scenario customization output <b>1341</b> to the user client <b>1304</b> to inform the user how ranges of values for other market factors have been affected by the change to the customized market factor. In some alternative embodiments, the scenario customization output may instead be sent to the administrative client <b>1302</b>. In one implementation, the scenario customization output may include data such as a response identifier, ranges of values for market factors, and/or the like. In one embodiment, the MLPO server may provide the following example scenario customization output, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00033" num="00033"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="273pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /scenario_customization_output.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><scenario_customization_output></entry></row><row><entry /><entry>  <response_identifier>ID_response_23</response_identifier></entry></row><row><entry /><entry>  <market_factors></entry></row><row><entry /><entry>    <market_factor></entry></row><row><entry /><entry>      <market_factor_identifier>ID_interest_rate_5Y</market_factor_identifier></entry></row><row><entry /><entry>      <minimum_range_value>-115.00</minimum_range_value></entry></row><row><entry /><entry>      <maximum_range_value>314.00</maximum_range_value></entry></row><row><entry /><entry>      <average_range_value>75.03</average_range_value></entry></row><row><entry /><entry>    </market_factor></entry></row><row><entry /><entry>    <market_factor></entry></row><row><entry /><entry>      <market_factor_identifier>ID_oil_price</market_factor_identifier></entry></row><row><entry /><entry>      <minimum_range_value>-49.00</minimum_range_value></entry></row><row><entry /><entry>      <maximum_range_value>19992.00</maximum_range_value></entry></row><row><entry /><entry>      <average_range_value>2698.92</average_range_value></entry></row><row><entry /><entry>    </market_factor></entry></row><row><entry /><entry>      ...</entry></row><row><entry /><entry>  </market_factors></entry></row><row><entry /><entry></scenario_customization_output></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0337The MLPO server <b>1306</b> may send a predefined scenario store request <b>1345</b> to the repository <b>1310</b> to facilitate storing the constructed predefined scenario. In one implementation, the predefined scenario may be stored as a set of customized market factors and specified ranges of values for customized market factors in the set, and the predefined scenario store request may include data such as a request identifier, a user identifier, a predefined scenario identifier, a simulation model, a pricing date, ranges of values for market factors, and/or the like. In one embodiment, the MLPO server may provide the following example predefined scenario store request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00034" num="00034"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="266pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /predefined_scenario_store_request.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><predefined_scenario_store_request></entry></row><row><entry /><entry>  <request_identifier>ID_request_24</request_identifier></entry></row><row><entry /><entry>  <user_identifier>ID_user_1</user_identifier></entry></row><row><entry /><entry>  <predefined_scenario_identifier></entry></row><row><entry /><entry>    ID_predefined_scenario_1</entry></row><row><entry /><entry>  </predefined_scenario_identifier></entry></row><row><entry /><entry>  <simulation_model>ID_neural_network_simulation_model_1Y</simulation_model></entry></row><row><entry /><entry>  <pricing_date>2020-04-17</pricing_date></entry></row><row><entry /><entry>  <customized_market_factors></entry></row><row><entry /><entry>    <customized_market_factor></entry></row><row><entry /><entry>      <market_factor_identifier>ID_oil_price</market_factor_identifier></entry></row><row><entry /><entry>      <minimum_range_value>-49.00</minimum_range_value></entry></row><row><entry /><entry>      <maximum_range_value>19992.00</maximum_range_value></entry></row><row><entry /><entry>      <average_range_value>2698.92</average_range_value></entry></row><row><entry /><entry>    </customized_market_factor></entry></row><row><entry /><entry>    <customized_market_factor></entry></row><row><entry /><entry>      <market_factor_identifier>ID_interest_rate_6M</market_factor_identifier></entry></row><row><entry /><entry>      <minimum_range_value>40.00</minimum_range_value></entry></row><row><entry /><entry>      <maximum_range_value>333.00</maximum_range_value></entry></row><row><entry /><entry>      <average_range_value>132.76</average_range_value></entry></row><row><entry /><entry>    </customized_market_factor></entry></row><row><entry /><entry>  </customized_market_factors></entry></row><row><entry /><entry></predefined_scenario_store_request></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0338In another implementation, the predefined scenario may be stored as a set of simulated market scenarios that satisfy specified ranges of values for customized market factors, and the predefined scenario store request may include data such as a request identifier, a user identifier, a predefined scenario identifier, a simulation identifier, a set of simulated market scenarios (e.g., filtered), and/or the like. In one embodiment, the MLPO server may provide the following example predefined scenario store request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00035" num="00035"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /predefined_scenario_store_request.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><predefined_scenario_store_request></entry></row><row><entry /><entry> <request_identifier>ID_request_24</request_identifier></entry></row><row><entry /><entry> <user_identifier>ID_user_1</user_identifier></entry></row><row><entry /><entry> <predefined_scenario_identifier></entry></row><row><entry /><entry>  ID_predefined_scenario_1</entry></row><row><entry /><entry> </predefined_scenario_identifier></entry></row><row><entry /><entry> <simulation_identifier>ID_sim_1</simulation_identifier></entry></row><row><entry /><entry> <scenario_identifiers>ID_scenario_1, ID_scenario_2, </entry></row><row><entry /><entry> ...</scenario_identifiers></entry></row><row><entry /><entry></predefined_scenario_store_request></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0339The repository <b>1310</b> may send a predefined scenario store response <b>1349</b> to the MLPO server <b>1306</b> to confirm that the constructed predefined scenario was stored successfully. In one implementation, the predefined scenario store response may include data such as a response identifier, a status, and/or the like. In one embodiment, the repository may provide the following example predefined scenario store response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00036" num="00036"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /predefined_scenario_store_response.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><predefined_scenario_store_response></entry></row><row><entry /><entry> <response_identifier>ID_response_24</response_identifier></entry></row><row><entry /><entry> <status>0K</status></entry></row><row><entry /><entry></predefined_scenario_store_response></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0340The MLPO server <b>1306</b> may send a predefined scenario construction response <b>1353</b> to the user client <b>1304</b> to inform the user that the constructed predefined scenario was stored successfully. In some alternative embodiments, the predefined scenario construction response may instead be sent to the administrative client <b>1302</b>. In one implementation, the predefined scenario construction response may include data such as a response identifier, a status, and/or the like. In one embodiment, the MLPO server may provide the following example predefined scenario construction response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00037" num="00037"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /predefined_scenario_construction_response.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><predefined_scenario_construction_response></entry></row><row><entry /><entry> <response_identifier>ID_response_21</response_identifier></entry></row><row><entry /><entry> <status>OK</status></entry></row><row><entry /><entry></predefined_scenario_construction_response></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0341<figref idref="DRAWINGS">FIGS. 14A-B</figref> show a logic flow illustrating embodiments of a predefined scenario constructing (PSC) component for the MLPO. In <figref idref="DRAWINGS">FIG. 14A</figref>, a predefined scenario construction request may be obtained at <b>1401</b>. For example, the predefined scenario construction request may be obtained as a result of a user requesting construction of a predefined scenario.

0342Market scenarios to utilize for constructing the predefined scenario may be determined at <b>1405</b>. In one embodiment, the market scenarios to utilize may be determined based on the simulation model (e.g., for a specified pricing date) and/or time period length selected by the user. In another embodiment, the market scenarios to utilize may be determined based on filters applied to simulated market scenarios. In one implementation, the predefined scenario construction request may be parsed (e.g., using PHP commands) to determine the market scenarios to utilize (e.g., based on the values of the simulation_model and/or pricing_date fields). For example, the selected simulation model and/or pricing date may be used to determine a simulation identifier (e.g., ID_sim_1) of the corresponding simulation (e.g., a set of simulated market scenarios).

0343The market scenarios to utilize may be retrieved from a database at <b>1409</b>. In one implementation, the market scenarios to utilize may be retrieved via a scenario results retrieve request.

0344Market factors to process may be determined at <b>1413</b>. For example, market factors may include interest rates, credit spread, oil price, equity indices, and/or the like. In one implementation, the market factors to process may be determined based on market factors utilized in the simulation. For example, the market factors to process may be determined via a MySQL database command similar to the following:

0000<tables id="TABLE-US-00038" num="00038"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>SELECT scenarioMarketFactorID</entry></row><row><entry /><entry>FROM ScenarioResults</entry></row><row><entry /><entry>WHERE simulationID = ID_sim_1;</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> In another implementation, a set of default market factors to process may be specified in a configuration setting.

0345A determination may be made at <b>1417</b> whether there remain market factors to process. In one implementation, each of the market factors may be processed. If there remain market factors to process, the next market factor (e.g., 6 month change in oil price) may be selected for processing at <b>1421</b>.

0346A factor group for the selected market factor may be determined at <b>1425</b>. In one embodiment, market factors may be organized into factor groups to facilitate searching for market factors by the user. For example, the change in oil prices market factor may be associated with the Macro factor group. In one implementation, the factor group associated with each market factor may be specified in a configuration setting. In some implementations, multiple factor groups may be associated with a market factor.

0347A range of market factor values for the selected market factor may be determined at <b>1429</b>. For example, the range may include a minimum market factor value, a maximum market factor value, an average market factor value, and/or the like for the market scenarios to utilize. In one implementation, the range of market factor values for each market factor may be precalculated. For example, the range of market factor values for the selected market factor may be determined via a MySQL database command similar to the following:

0000<tables id="TABLE-US-00039" num="00039"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="7pt" align="left" /><colspec colname="2" colwidth="210pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>SELECT simulationMarketFactorRangeMin, </entry></row><row><entry /><entry> simulationMarketFactorRangeMax,</entry></row><row><entry /><entry> simulationMarketFactorRangeAverage</entry></row><row><entry /><entry>FROM ScenarioResults</entry></row><row><entry /><entry>WHERE simulationID = ID_sim_1 AND scenarioMarketFactorID = </entry></row><row><entry /><entry>ID_oil_price;</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> In another implementation, the range of market factor values for each market factor may be determined by iterating through the market scenarios to utilize and calculating the range based on the market factor values for the market scenarios to utilize. For example, the range of market factor values for the selected market factor may be determined via a MySQL database command similar to the following:

0000<tables id="TABLE-US-00040" num="00040"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="7pt" align="left" /><colspec colname="2" colwidth="210pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>SELECT MIN(scenarioSimulatedMarketFactorChange),</entry></row><row><entry /><entry> MAX(scenarioSimulatedMarketFactorChange), </entry></row><row><entry /><entry> AVG(scenarioSimulatedMarketFactorChange)</entry></row><row><entry /><entry>FROM ScenarioResults</entry></row><row><entry /><entry>WHERE simulationID = ID_sim_1 AND scenarioMarketFactorID = </entry></row><row><entry /><entry>ID_oil_price;</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0348A set of customized market factors may be determined at <b>1433</b>. For example, a market factor may be customized by specifying a subrange of allowable values for the market factor. In one embodiment, the user may utilize a user interface widget to create a new predefined scenario (e.g., with no customized market factors). In another embodiment, the user may utilize a user interface widget to select an existing predefined scenario with a set of customized market factors. In one implementation, the set of customized market factors for a predefined scenario (e.g., with identifier ID_predefined_scenario_1) may be retrieved from a database. For example, the set of customized market factors for the predefined scenario may be determined via a MySQL database command similar to the following:

0000<tables id="TABLE-US-00041" num="00041"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>SELECT customizedMarketFactorID</entry></row><row><entry /><entry>FROM PredefinedScenarios</entry></row><row><entry /><entry>WHERE predefinedScenarioID = ID_predefined_scenario_1;</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0349The market scenarios to utilize may be filtered based on the set of customized market factors at <b>1437</b>. In one embodiment, the market scenarios to utilize may be filtered to the subset of market scenarios that satisfy the subrange of allowable values for each customized market factor. See <figref idref="DRAWINGS">FIG. 14B</figref> for additional details regarding filtering the market scenarios to utilize based on customized market factors.

0350A determination may be made at <b>1441</b> whether there remain market factors to process. In one implementation, each of the market factors may be processed to determine ranges for the filtered market scenarios. If there remain market factors to process, the next market factor (e.g., 6 month change in oil price) may be selected for processing at <b>1445</b>.

0351A determination may be made at <b>1449</b> whether there remain filtered market scenarios to analyze. In one implementation, each of the filtered market scenarios may be analyzed. If there remain filtered market scenarios to analyze, the next filtered market scenario (e.g., with identifier ID_scenario_1) may be selected for analysis at <b>1453</b>.

0352A market factor value of the selected market factor for the selected filtered market scenario may be determined at <b>1457</b>. In one implementation, the market factor value may be retrieved from a database. For example, the market factor value of the selected market factor for the selected market scenario may be determined via a MySQL database command similar to the following:

0000<tables id="TABLE-US-00042" num="00042"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="7pt" align="left" /><colspec colname="2" colwidth="210pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>SELECT scenarioSimulatedMarketFactorChange</entry></row><row><entry /><entry>FROM ScenarioResults</entry></row><row><entry /><entry>WHERE simulationID = ID_sim_1 AND scenarioID = ID_scenario_1 </entry></row><row><entry /><entry> AND scenarioMarketFactorID = ID_oil_price;</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0353The determined market factor values may be analyzed to determine a range of filtered market factor values for the selected market factor at <b>1461</b>. For example, the range may include a minimum market factor value, a maximum market factor value, an average market factor value, and/or the like for the filtered market scenarios.

0354A visualization of the market factors may be generated at <b>1465</b>. In one embodiment, the visualization may show the range of unfiltered market factor values and/or the range of filtered market factor values for each of the market factors. In one implementation, a user interface widget may be generated for each of the market factors showing the range of unfiltered market factor values and/or the range of filtered market factor values for the respective market factor. See <figref idref="DRAWINGS">FIGS. 15-19</figref> for examples of visualizations that may be generated.

0355A determination may be made at <b>1469</b> whether a scenario customization input was obtained from the user. In one embodiment, the scenario customization input may be a user interface input from the user with a user-specified range of allowable values for an updated market factor. If a scenario customization input was obtained, the specified range of allowable values for the updated market factor may be determined at <b>1473</b>. For example, the user may specify an updated subrange of allowable values for a customized market factor (e.g., an existing customized market factor, a newly customized market factor). In another example, the user may specify that a previously customized market factor should no longer be customized (e.g., by updating the subrange of allowable values to the full range for the previously customized market factor). In one implementation, the scenario customization input may be parsed (e.g., using PHP commands) to determine the specified range of allowable values for the updated market factor (e.g., based on the values of the market_factor_identifier, minimum_range_value, and/or maximum_range_value fields). The set of customized market factors may be updated at <b>1477</b>. In one embodiment, a newly customized market factor may be added to the set of customized market factors. In another embodiment, a previously customized market factor may be removed from the set of customized market factors. In one implementation, a list (e.g., an array of market factor identifiers, a map of market factor identifier values to customized status Boolean values) of customized market factors may be updated. The market scenarios to utilize may be filtered based on the updated set of customized market factors and an updated visualization of the market factors may be generated as discussed with regard to <b>1437</b>-<b>1465</b>.

0356A determination may be made at <b>1481</b> whether a scenario save input was obtained from the user. In one embodiment, the scenario save input may be a user interface input from the user indicating that the predefined scenario should be saved. If a scenario save input was obtained, the predefined scenario may be stored at <b>1485</b>. In one implementation, the predefined scenario may be stored via a predefined scenario store request.

0357<figref idref="DRAWINGS">FIG. 14B</figref> shows additional details regarding filtering the market scenarios to utilize based on customized market factors. In <figref idref="DRAWINGS">FIG. 14B</figref>, filtered market scenarios (e.g., an array of filtered market scenario identifiers, a map of market scenario identifier values to filtered status Boolean values) may be set to the market scenarios to utilize at <b>1402</b> (e.g., to clear any previously set filters).

0358A determination may be made at <b>1406</b> whether there remain customized market factors to process. In one implementation, each of the market factors in the set of customized market factors may be processed. If there remain customized market factors to process, the next customized market factor may be selected for processing at <b>1410</b>.

0359The specified range of allowable values for the selected customized market factor may be determined at <b>1414</b>. For example, the specified range of allowable values may include a minimum value and a maximum value. In one implementation, the specified range of allowable values for the selected customized market factor may be determined as discussed with regard to <b>1473</b> (e.g., for a new user-specified range). In another implementation, the specified range of allowable values for the selected customized market factor may be retrieved from a database (e.g., for an existing predefined scenario). For example, the specified range of allowable values for the selected customized market factor may be determined via a MySQL database command similar to the following:

0000<tables id="TABLE-US-00043" num="00043"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>SELECT customizedMarketFactorRangeMin, </entry></row><row><entry /><entry>customizedMarketFactorRangeMax</entry></row><row><entry /><entry>FROM PredefinedScenarios</entry></row><row><entry /><entry>WHERE predefinedScenarioID = ID_predefined_scenario_1;</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0360A determination may be made at <b>1418</b> whether there remain filtered market scenarios to analyze. In one implementation, each of the market scenarios that have not been removed from the filtered market scenarios (e.g., during processing of previously processed customized market factors) may be analyzed. If there remain filtered market scenarios to analyze, the next filtered market scenario may be selected for analysis at <b>1422</b>.

0361A market factor value of the selected customized market factor for the selected filtered market scenario may be determined at <b>1426</b>. In one implementation, the market factor value may be retrieved from a database. For example, the market factor value of the selected customized market factor for the selected filtered market scenario may be determined via a MySQL database command similar to the following:

0000<tables id="TABLE-US-00044" num="00044"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="7pt" align="left" /><colspec colname="2" colwidth="210pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>SELECT scenarioSimulatedMarketFactorChange</entry></row><row><entry /><entry>FROM ScenarioResults</entry></row><row><entry /><entry>WHERE simulationID = ID_sim_1 AND scenarioID = ID_scenario_1 </entry></row><row><entry /><entry> AND scenarioMarketFactorID = ID_oil_price;</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0362A determination may be made at <b>1430</b> whether the determined market factor value is in the specified range of allowable values for the selected customized market factor. If the determined market factor value is outside the specified range of allowable values for the selected customized market factor, the selected filtered market scenario may be removed from the filtered market scenarios at <b>1434</b>.

0363Once the customized market factors have been processed, the remaining filtered market scenarios may be returned at <b>1438</b>. In one embodiment, the returned filtered market scenarios are market scenarios having market factor values that fall within the subrange of allowable values for each of the market factors in the set of customized market factors.

0364<figref idref="DRAWINGS">FIG. 15</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 15</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for constructing a predefined scenario is illustrated. Screen <b>1501</b> shows that a user may utilize a load predefined scenario widget <b>1505</b> to select an existing predefined scenario (e.g., from predefined scenarios associated with the user's user identifier). The user may utilize an add new predefined scenario widget <b>1510</b> to create a new predefined scenario.

0365The user may utilize a pricing date widget <b>1515</b> and/or a simulation model widget <b>1520</b> to specify market scenarios to utilize. The user may search through market factors associated with the market scenarios to utilize by filtering displayed market factors using factor group filter widgets (e.g., <b>1525</b>A-D). For example, utilizing All factor group widget <b>1525</b>A may show unfiltered market factors associated with the market scenarios to utilize. In another example, utilizing Macro factor group widget <b>1525</b>D may filter market factors to show market factors associated with the Macro factor group (e.g., change in oil price). The user may search through market factors associated with the market scenarios to utilize by filtering displayed market factors by market factor name using search by factor name widget <b>1527</b>.

0366The user may view and/or modify ranges of allowable values for each market factor using market factor widgets (e.g., <b>1530</b>A-C). For example, screen <b>1501</b> shows that ranges of allowable values for the market factors have not been modified (e.g., there are no customized market factors).

0367<figref idref="DRAWINGS">FIG. 16</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 16</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for constructing a predefined scenario is illustrated. Screen <b>1601</b> shows that the user may modify ranges of allowable values for market factors of a predefined scenario (e.g., an existing predefined scenario selected using the load predefined scenario widget <b>1605</b>, a new predefined scenario created using the add new predefined scenario widget <b>1610</b>) using allowable range widgets (e.g., <b>1635</b>A-C). Screen <b>1601</b> shows that when the user modifies the range of allowable values for a market factor, an updated visualization showing how ranges of allowable values for the market factors have been affected may be generated. For example, if the user modifies (e.g., using widget <b>1635</b>B) the range of allowable values for the 6 month interest rate market factor (e.g., shown in widget <b>1630</b>B (e.g., rearranged in order and/or highlighted to indicate a customized market factor)), an updated visualization showing how the range of allowable values (e.g., shown in widget <b>1635</b>A) for the 3 month interest rate market factor (e.g., shown in widget <b>1630</b>A) and how the range of allowable values (e.g., shown in widget <b>1635</b>C) for the 1 year interest rate market factor (e.g., shown in widget <b>1630</b>C) have changed based on the user-specified scenario customization input may be generated.

0368<figref idref="DRAWINGS">FIG. 17</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 17</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for constructing a predefined scenario is illustrated. Screen <b>1701</b> shows that the user may utilize the Macro factor group widget <b>1725</b>D to view how the ranges of allowable values (e.g., shown in widgets <b>1735</b>D-F) for market factors associated with the Macro factor group (e.g., shown in widget <b>1730</b>D-F) have changed based on the user-specified scenario customization input.

0369<figref idref="DRAWINGS">FIG. 18</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 18</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for constructing a predefined scenario is illustrated. Screen <b>1801</b> shows that when the user modifies the range of allowable values for another market factor (e.g., associated with the Macro factor group), an updated visualization showing how ranges of allowable values for the market factors have been affected (e.g., based on both modifications) may be generated. For example, if the user modifies (e.g., using widget <b>1835</b>D) the range of allowable values for the oil price market factor (e.g., shown in widget <b>1830</b>D (e.g., rearranged in order and/or highlighted to indicate a customized market factor)), an updated visualization showing how the range of allowable values (e.g., shown in widget <b>1835</b>E) for the VIX market factor (e.g., shown in widget <b>1830</b>E) and how the range of allowable values (e.g., shown in widget <b>1835</b>F) for the Commodities market factor (e.g., shown in widget <b>1830</b>F) have changed based on the two user-specified scenario customization inputs may be generated.

0370<figref idref="DRAWINGS">FIG. 19</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 19</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for constructing a predefined scenario is illustrated. Screen <b>1901</b> shows that the user may utilize the All factor group widget <b>1925</b>A to view how the ranges of allowable values for the market factors have changed based on the user-specified scenario customization inputs. For example, market factor widget <b>1930</b>A shows how the range of allowable values (e.g., shown in widget <b>1935</b>A) for the 3 month interest rate market factor has changed based on the user-specified changes to the range of allowable values (e.g., shown in widget <b>1935</b>B) for the 6 month interest rate market factor (e.g., shown in widget <b>1930</b>B) and to the range of allowable values (e.g., shown in widget <b>1935</b>D) for the oil price market factor (e.g., shown in widget <b>1930</b>D). The user may save the predefined scenario using a save widget <b>1940</b>.

0371<figref idref="DRAWINGS">FIG. 20</figref> shows a datagraph illustrating data flow(s) for the MLPO. In <figref idref="DRAWINGS">FIG. 20</figref>, dashed lines indicate data flow elements that may be more likely to be optional. In <figref idref="DRAWINGS">FIG. 20</figref>, a user client <b>2004</b> (e.g., of a user) may send a portfolio returns visualization request <b>2021</b> to a MLPO server <b>2006</b> to facilitate generating a portfolio returns visualization based on customized market factors. For example, the user client may be a desktop, a laptop, a tablet, a smartphone, a smartwatch, and/or the like that is executing a client application. In one implementation, the portfolio returns visualization request may include data such as a request identifier, a user identifier, a predefined scenario identifier, a simulation model, a pricing date, a portfolio identifier, and/or the like. In one embodiment, the user client may provide the following example portfolio returns visualization request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00045" num="00045"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /portfolio_returns_visualization_request.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><portfolio_returns_visualization_request></entry></row><row><entry /><entry> <request_identifier>ID_request_31</request_identifier></entry></row><row><entry /><entry> <user_identifier>ID_user_1</user_identifier></entry></row><row><entry /><entry> <predefined_scenario_identifier></entry></row><row><entry /><entry>  ID_predefined_scenario_1</entry></row><row><entry /><entry> </predefined_scenario_identifier></entry></row><row><entry /><entry> <simulation_model>ID_neural_network_simulation_model_1Y</entry></row><row><entry /><entry> </simulation_model></entry></row><row><entry /><entry> <pricing_date>2020-04-17</pricing_date></entry></row><row><entry /><entry> <portfolio_identifier>ID_portfolio_1</portfolio_identifier></entry></row><row><entry /><entry></portfolio_returns_visualization_request></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0372The MLPO server <b>2006</b> may send an expected returns retrieve request <b>2023</b> to a repository <b>2010</b> to facilitate retrieving expected returns for securities in the portfolio for simulated scenarios corresponding to the specified simulation (e.g., with a simulation identifier determined based on the specified pricing date and/or simulation model). In one implementation, the expected returns retrieve request may include data such as a request identifier, expected returns to retrieve specification, and/or the like. In one embodiment, the MLPO server may provide the following example expected returns retrieve request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00046" num="00046"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /expected_returns_retrieve_request.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><expected_returns_retrieve_request></entry></row><row><entry /><entry> <request_identifier>ID_request_32</request_identifier></entry></row><row><entry /><entry> <expected_returns_specification></entry></row><row><entry /><entry>  <simulation_identifier>ID_sim_1</simulation_identifier></entry></row><row><entry /><entry>  <scenario></entry></row><row><entry /><entry>   <scenario_identifier>ID_scenario_1</scenario_identifier></entry></row><row><entry /><entry>   <securities>MSFT, AAPL, ...</securities></entry></row><row><entry /><entry>  </scenario></entry></row><row><entry /><entry>  <scenario></entry></row><row><entry /><entry>   <scenario_identifier>ID_scenario_2</scenario_identifier></entry></row><row><entry /><entry>   <securities>MSFT, AAPL, ...</securities></entry></row><row><entry /><entry>  </scenario></entry></row><row><entry /><entry>  ...</entry></row><row><entry /><entry> </expected_returns_specification></entry></row><row><entry /><entry></expected_returns_retrieve_request></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0373The repository <b>2010</b> may send an expected returns retrieve response <b>2025</b> to the MLPO server <b>2006</b> with the requested expected returns data. In one implementation, the expected returns retrieve response may include data such as a response identifier, the requested expected returns data, and/or the like. In one embodiment, the repository may provide the following example expected returns retrieve response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00047" num="00047"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /expected_returns_retrieve_response.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry></entry></row><row><entry /><entry><expected_returns_retrieve_response></entry></row><row><entry /><entry> <response_identifier>ID_response_32</response_identifier></entry></row><row><entry /><entry> <expected_returns></entry></row><row><entry /><entry>  <scenario></entry></row><row><entry /><entry>   <scenario_identifier>ID_scenario_1</scenario_identifier></entry></row><row><entry /><entry>   <security></entry></row><row><entry /><entry>    <security_identifier>MSFT</security_identifier></entry></row><row><entry /><entry>    <expected_return>10%</expected_return></entry></row><row><entry /><entry>   </security></entry></row><row><entry /><entry>   <security></entry></row><row><entry /><entry>    <security_identifier>AAPL</security_identifier></entry></row><row><entry /><entry>    <expected_return>12%</expected_return></entry></row><row><entry /><entry>   </security></entry></row><row><entry /><entry>   ...</entry></row><row><entry /><entry>  </scenario></entry></row><row><entry /><entry>  <scenario></entry></row><row><entry /><entry>   <scenario_identifier>ID_scenario_2</scenario_identifier></entry></row><row><entry /><entry>   <security></entry></row><row><entry /><entry>    <security_identifier>MSFT</security_identifier></entry></row><row><entry /><entry>    <expected_return>15%</expected_return></entry></row><row><entry /><entry>   </security></entry></row><row><entry /><entry>   <security></entry></row><row><entry /><entry>    <security_identifier>AAPL</security_identifier></entry></row><row><entry /><entry>    <expected_return>13%</expected_return></entry></row><row><entry /><entry>   </security></entry></row><row><entry /><entry>   ...</entry></row><row><entry /><entry>  </scenario></entry></row><row><entry /><entry>  ...</entry></row><row><entry /><entry> </expected_returns></entry></row><row><entry /><entry></expected_returns_retrieve_response></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0374The MLPO server <b>2006</b> may send a predefined scenario retrieve request <b>2027</b> to the repository <b>2010</b> to facilitate retrieving the specified predefined scenario. In one implementation, the predefined scenario retrieve request may include data such as a request identifier, a user identifier, a predefined scenario identifier, and/or the like. In one embodiment, the MLPO server may provide the following example predefined scenario retrieve request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00048" num="00048"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>POST /predefined_scenario_retrieve_request.php HTTP/1.1</entry></row><row><entry /><entry>Host: www.server.com</entry></row><row><entry /><entry>Content-Type: Application/XML</entry></row><row><entry /><entry>Content-Length: 667</entry></row><row><entry /><entry><?XML version = “1.∅” encoding = “UTF-8”></entry></row><row><entry /><entry><predefined_scenario_retrieve_request></entry></row><row><entry /><entry> <request_identifier>ID_request_33</request_identifier></entry></row><row><entry /><entry> <user_identifier>ID_user_1</user_identifier></entry></row><row><entry /><entry> <predefined_scenario_identifier></entry></row><row><entry /><entry>  ID_predefined_scenario_1</entry></row><row><entry /><entry> </predefined_scenario_identifier></entry></row><row><entry /><entry></predefined_scenario_retrieve_request></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0375The repository <b>2010</b> may send a predefined scenario retrieve response <b>2029</b> to the MLPO server <b>2006</b> with the requested predefined scenario data. In one implementation, the predefined scenario retrieve response may include data such as a response identifier, the requested predefined scenario data, and/or the like. In one embodiment, the repository may provide the following example predefined scenario retrieve response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00049" num="00049"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /predefined_scenario_retrieve_response.php HTTP/1.1 </entry></row><row><entry>Host: www.server.com </entry></row><row><entry>Content-Type: Application/XML </entry></row><row><entry>Content-Length: 667 </entry></row><row><entry> </entry></row><row><entry><predefined_scenario_retrieve_response> </entry></row><row><entry> <response_identifier>ID_response_33</response_identifier> </entry></row><row><entry> <customized_market_factors> </entry></row><row><entry>  <customized_market_factor> </entry></row><row><entry>   <market_factor_identifier>ID_oil_price</market_factor_identifier> </entry></row><row><entry>   <minimum_range_value>−49.00</minimum_range_value> </entry></row><row><entry>   <maximum_range_value>19992.00</maximum_range_value> </entry></row><row><entry>   <average_range_value>2698.92</average_range_value> </entry></row><row><entry>  </customized_market_factor> </entry></row><row><entry>  <customized_market_factor> </entry></row><row><entry>   <market_factor_identifier>ID_interest_rate_6M</market_factor_ </entry></row><row><entry>   identifier> </entry></row><row><entry>   <minimum_range_value>40.00</minimum_range_value> </entry></row><row><entry>   <maximum_range_value>333.00</maximum_range_value> </entry></row><row><entry>   <average_range_value>132.76</average_range_value> </entry></row><row><entry>  </customized_market_factor> </entry></row><row><entry> </customized_market_factors> </entry></row><row><entry></predefined_scenario_retrieve_response> </entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0376A scenario based portfolio returns visualizing (SPRV) component <b>2033</b> may utilize data provided in the portfolio returns visualization request to generate a portfolio return metrics visualization. See <figref idref="DRAWINGS">FIG. 21</figref> for additional details regarding the SPRV component.

0377The MLPO server <b>2006</b> may send a portfolio returns visualization response <b>2037</b> to the user client <b>2004</b> to provide a visualization of portfolio return metrics for the specified portfolio under the specified predefined scenario. In one implementation, the portfolio returns visualization response may include data such as a response identifier, visualization data, and/or the like. In one embodiment, the MLPO server may provide the following example portfolio returns visualization response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00050" num="00050"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /portfolio_returns_visualization_response.php HTTP/1.1 </entry></row><row><entry>Host: www.server.com </entry></row><row><entry>Content-Type: Application/XML </entry></row><row><entry>Content-Length: 667 </entry></row><row><entry> </entry></row><row><entry><portfolio_returns_visualization_response> </entry></row><row><entry> <response_identifier>ID_response_31</response_identifier> </entry></row><row><entry> <visualization_data> </entry></row><row><entry>  portfolio return metrics data (e.g., constituent securities' and/or </entry></row><row><entry>  portfolio's returns, worst returns, return volatility, frequency vs. </entry></row><row><entry>  returns data) </entry></row><row><entry> </visualization_data> </entry></row><row><entry></portfolio_returns_visualization_response> </entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0378If the user customizes a market factor, the user client <b>2004</b> may send a visualization scenario customization input <b>2041</b> to the MLPO server <b>2006</b> specifying a range of values for the customized market factor (e.g., to modify the predefined scenario). In one implementation, the visualization scenario customization input may include data such as a request identifier, a market factor identifier, a minimum range value, a maximum range value, and/or the like. In one embodiment, the user client may provide the following example visualization scenario customization input, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00051" num="00051"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /visualization_scenario_customization_input.php HTTP/1.1 </entry></row><row><entry>Host: www.server.com </entry></row><row><entry>Content-Type: Application/XML </entry></row><row><entry>Content-Length: 667 </entry></row><row><entry> </entry></row><row><entry><visualization_scenario_customization_input> </entry></row><row><entry> <request_identifier>ID_request_34</request_identifier> </entry></row><row><entry> <market_factor_identifier>ID_VIX</market_factor_identifier> </entry></row><row><entry> <minimum_range_value>913.00</minimum_range_value> </entry></row><row><entry> <maximum_range_value>5141.00</maximum_range_value> </entry></row><row><entry></visualization_scenario_customization_input> </entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0379The MLPO server <b>2006</b> may send a visualization scenario customization output <b>2045</b> to the user client <b>2004</b> to provide an updated visualization of portfolio return metrics for the specified portfolio (e.g., under the modified predefined scenario). In one implementation, the visualization scenario customization output may include data such as a response identifier, visualization data, and/or the like. In one embodiment, the MLPO server may provide the following example visualization scenario customization output, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00052" num="00052"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /visualization_scenario_customization_output.php HTTP/1.1 </entry></row><row><entry>Host: www.server.com </entry></row><row><entry>Content-Type: Application/XML </entry></row><row><entry>Content-Length: 667 </entry></row><row><entry> </entry></row><row><entry><visualization_scenario_customization_output> </entry></row><row><entry> <response_identifier>ID_response_34</response_identifier> </entry></row><row><entry> <visualization_data> </entry></row><row><entry>  portfolio return metrics data (e.g., constituent securities' and/or </entry></row><row><entry>  portfolio's returns, worst returns, return volatility, frequency vs. </entry></row><row><entry>  returns data) </entry></row><row><entry> </visualization_data> </entry></row><row><entry></visualization_scenario_customization_output> </entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0380<figref idref="DRAWINGS">FIG. 21</figref> shows a logic flow illustrating embodiments of a scenario based portfolio returns visualizing (SPRV) component for the MLPO. In <figref idref="DRAWINGS">FIG. 21</figref>, a portfolio returns visualization request may be obtained at <b>2101</b>. For example, the portfolio returns visualization request may be obtained as a result of a user requesting generation of a portfolio returns visualization.

0381Market scenarios to utilize for generating the portfolio returns visualization may be determined at <b>2105</b>. In one embodiment, the market scenarios to utilize may be determined based on the simulation model (e.g., for a specified pricing date) and/or time period length selected by the user. In another embodiment, the market scenarios to utilize may be determined based on filters applied to simulated market scenarios. In one implementation, the portfolio returns visualization request may be parsed (e.g., using PHP commands) to determine the market scenarios to utilize (e.g., based on the values of the simulation_model and/or pricing_date fields). For example, the selected simulation model and/or pricing date may be used to determine a simulation identifier (e.g., ID_sim_1) of the corresponding simulation (e.g., a set of simulated market scenarios).

0382Portfolio securities of a portfolio may be determined at <b>2109</b> and portfolio securities weights for the portfolio securities may be determined at <b>2113</b>. In one embodiment, the portfolio securities and/or the corresponding portfolio securities weights may be retrieved from a database (e.g., based on a portfolio identifier). In one implementation, the portfolio returns visualization request may be parsed (e.g., using PHP commands) to determine the portfolio identifier (e.g., based on the value of the portfolio_identifier field). In another embodiment, the portfolio securities and/or the corresponding portfolio securities weights may be specified by the user. In one implementation, the portfolio returns visualization request may be parsed (e.g., using PHP commands) to determine the specified portfolio securities and/or the corresponding portfolio securities weights. In another embodiment, the portfolio securities and/or the corresponding portfolio securities weights may be determined based on an optimization. In one implementation, the portfolio securities and/or the corresponding portfolio securities weights may be determined as discussed with regard to the PC component.

0383Expected returns of the portfolio securities for the market scenarios to utilize may be retrieved from a database at <b>2117</b>. For example, the expected returns may be cached to facilitate expected return metrics calculations. In one implementation, the expected returns may be retrieved via an expected returns retrieve request.

0384A determination may be made at <b>2121</b> whether there remain portfolio securities to process. In one implementation, each of the constituent portfolio securities may be processed. If there remain portfolio securities to process, the next security (e.g., with identifier MSFT) may be selected for processing at <b>2125</b>.

0385A determination may be made at <b>2129</b> whether there remain market scenarios to analyze. In one implementation, each of the market scenarios to utilize may be analyzed. If there remain market scenarios to analyze, the next market scenario (e.g., with identifier ID_scenario_1) may be selected for analysis at <b>2133</b>.

0386An expected return for the selected security for the selected market scenario may be determined at <b>2137</b>. In one implementation, the expected return may be retrieved from cache. In another implementation, the expected return may be retrieved from a database. For example, the expected return for the selected security for the selected market scenario may be determined via a MySQL database command similar to the following:

0000<tables id="TABLE-US-00053" num="00053"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>SELECT linkedScenarioSecurityExpectedReturn </entry></row><row><entry>FROM ExpectedReturns </entry></row><row><entry>WHERE securityID = “MSFT” AND linkedSimulationID = ID_sim_1 </entry></row><row><entry>AND </entry></row><row><entry> linkedScenarioID = ID_scenario_1;</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0387Expected security return metrics for the selected security for the market scenarios to utilize may be calculated at <b>2141</b>. For example, the expected security return metrics for a security may include the security's expected return, worst returns, return volatility, frequency vs. returns data, and/or the like. In one implementation, the expected security return metrics for each security may be determined by iterating through the market scenarios to utilize and calculating the expected security return metrics based on the expected returns (e.g., cached) for the market scenarios to utilize. For example, the expected return for the selected security for the market scenarios to utilize may be determined via a MySQL database command similar to the following:

0000<tables id="TABLE-US-00054" num="00054"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>SELECT AVG(linkedScenarioSecurityExpectedReturn) </entry></row><row><entry>FROM ExpectedReturns </entry></row><row><entry>WHERE securityID = “MSFT” AND linkedSimulationID = ID_sim_1;</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0388Expected portfolio return metrics for the portfolio for the market scenarios to utilize may be calculated at <b>2145</b>. For example, the expected portfolio return metrics for a portfolio may include the portfolio's expected return, worst returns, return volatility, frequency vs. returns data, and/or the like. In various implementations, the expected portfolio return metrics for the portfolio may be calculated using a weighted average (e.g., weighted based on the portfolio securities weights) of the expected security returns and/or of the calculated expected security return metrics for the constituent securities of the portfolio. For example, the following API may be utilized to determine the expected portfolio return metrics for the portfolio for the market scenarios to utilize:

0389POST API/RUNANALYSIS <ul id="ul0038" list-style="none"><li id="ul0038-0001" num="0000"><ul id="ul0039" list-style="none"><li id="ul0039-0001" num="0390">This API facilitates generating portfolio return metrics visualization for a specified portfolio (e.g., list of securities). The portfolio return metrics calculation results are included in the Summary object returned by the API.</li><li id="ul0039-0002" num="0391">The API returns HTTP/1.1 status code 201 if the request is successful. It returns 500 Internal Server Error if there is an exception.</li></ul></li></ul>

0392Input Parameter Details

0000<tables id="TABLE-US-00055" num="00055"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="28pt" align="left" /><colspec colname="4" colwidth="91pt" align="left" /><thead><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>Attribute name</entry><entry>Mandatory</entry><entry>Default</entry><entry>Description/Rule</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>securityInputs</entry><entry>Y</entry><entry /><entry>Specify the initial</entry></row><row><entry /><entry /><entry /><entry>investment</entry></row><row><entry>cash</entry><entry>N</entry><entry>0</entry><entry>Integer between 1 and 50</entry></row><row><entry>modelId</entry><entry>Y</entry><entry>1</entry><entry>Integer, either 1 or 4</entry></row><row><entry /><entry /><entry /><entry>based on the model</entry></row><row><entry>simulationId</entry><entry>Y</entry><entry>0</entry><entry>Taxable = 1, Tax-Exempt = 0</entry></row><row><entry>simulationInputs</entry><entry>Y</entry><entry /><entry>List of factor min and max</entry></row><row><entry /><entry /><entry /><entry>range for filtering of</entry></row><row><entry /><entry /><entry /><entry>scenarios</entry></row><row><entry>businessCycleInputs</entry><entry>N</entry><entry /><entry>List of business cycle</entry></row><row><entry /><entry /><entry /><entry>inputs and associated</entry></row><row><entry /><entry /><entry /><entry>percentages. (e.g., Late</entry></row><row><entry /><entry /><entry /><entry>Cycle 50% and Recession</entry></row><row><entry /><entry /><entry /><entry>50%)</entry></row><row><entry>pricingDt</entry><entry>Y</entry><entry /><entry>Current Pricing Date for</entry></row><row><entry /><entry /><entry /><entry>which simulation data is</entry></row><row><entry /><entry /><entry /><entry>available</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00056" num="00056"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>REQUEST</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry>POST API/runAnalysis </entry></row><row><entry /><entry>Content-type: application/json </entry></row><row><entry /><entry>{</entry></row><row><entry /><entry>  “securityInputs”: [{</entry></row><row><entry /><entry>         “fmrCusip”: “EAFE”, </entry></row><row><entry /><entry>         “description”:“EAFE”“, </entry></row><row><entry /><entry>         “qty“: 200000 </entry></row><row><entry /><entry>      }, {</entry></row><row><entry /><entry>         “fmrCusip”: “DHI270000”, </entry></row><row><entry /><entry>         “description”: “USTB 3.375% 11/15/48, </entry></row><row><entry /><entry>         “qty”: 200000 </entry></row><row><entry /><entry>      }</entry></row><row><entry /><entry>      .... </entry></row><row><entry /><entry>  ], </entry></row><row><entry /><entry>  ″cash″: 0, </entry></row><row><entry /><entry>  ″modelId″: 1, </entry></row><row><entry /><entry>  ″simulationId″: 1, </entry></row><row><entry /><entry>  ″pricingDt″: ″01/01/2020″, </entry></row><row><entry /><entry>  ″simulationInputs″: [{</entry></row><row><entry /><entry>          “factorName”: “VIX”, </entry></row><row><entry /><entry>          “rangeStart”: -3544, </entry></row><row><entry /><entry>          “rangeEnd”: 5513 </entry></row><row><entry /><entry>       }, {</entry></row><row><entry /><entry>          “factorName”: ″SP500″, </entry></row><row><entry /><entry>          “rangeStart”: −4648, </entry></row><row><entry /><entry>          “rangeEnd”: 2947}</entry></row><row><entry /><entry>   ], </entry></row><row><entry /><entry>  ″businessCycleInputs″: [{</entry></row><row><entry /><entry>           cycleName: ″Late″, </entry></row><row><entry /><entry>           percentage: 100 </entry></row><row><entry /><entry>        }, {</entry></row><row><entry /><entry>           cycleName: ″Recession″, </entry></row><row><entry /><entry>           percentage: 0 </entry></row><row><entry /><entry>     }]</entry></row><row><entry /><entry> ... </entry></row><row><entry /><entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry>RESPONSE</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry>201 </entry></row><row><entry /><entry>Content-Type: application/json </entry></row><row><entry /><entry>{</entry></row><row><entry /><entry>  ″summary″: {</entry></row><row><entry /><entry>         “risk”: 234.42. </entry></row><row><entry /><entry>         “avg5Percenti1e”: −202.09 </entry></row><row><entry /><entry>     }, </entry></row><row><entry /><entry>  “marketReturns”: [   {</entry></row><row><entry /><entry>         ″marketId″: 959, </entry></row><row><entry /><entry>         ″bucketId″: 4, </entry></row><row><entry /><entry>         ″marketReturn″: −434.16 </entry></row><row><entry /><entry>       }, {</entry></row><row><entry /><entry>         ″marketId″: 2527, </entry></row><row><entry /><entry>         ″bucketId″: 6, </entry></row><row><entry /><entry>         ″marketReturn″: −252.16 </entry></row><row><entry /><entry>       }, </entry></row><row><entry /><entry>        ... </entry></row><row><entry /><entry>    ]</entry></row><row><entry /><entry>}</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0393A visualization of the expected portfolio return metrics for the portfolio and/or of the expected security return metrics for the constituent securities of the portfolio for the market scenarios to utilize may be generated at <b>2149</b>. In one implementation, user interface widgets showing the expected portfolio return metrics and/or the expected security return metrics may be generated via a portfolio returns visualization response. See <figref idref="DRAWINGS">FIGS. 22-25</figref> for examples of visualizations that may be generated.

0394A determination may be made at <b>2153</b> whether a predefined scenario selection input was obtained from the user. In one embodiment, the predefined scenario selection input may be a user interface input from the user with a user-specified predefined scenario selection. For example, the user may select a predefined scenario to determine how expected portfolio return metrics for the portfolio and/or for the constituent securities of the portfolio would change with market factor customizations specified in the predefined scenario.

0395If a predefined scenario selection input was obtained, the set of customized market factors associated with the selected predefined scenario may be determined at <b>2157</b>. In one implementation, the market factor customizations specified in the predefined scenario may be obtained via a predefined scenario retrieve response, and the predefined scenario retrieve response may be parsed (e.g., using PHP commands) to determine the set of customized market factors (e.g., based on the values of the market_factor_identifier fields).

0396The market scenarios to utilize may be filtered based on the set of customized market factors at <b>2161</b>. In one embodiment, the market scenarios to utilize may be filtered to the subset of market scenarios that satisfy the subrange of allowable values for each customized market factor. See <figref idref="DRAWINGS">FIG. 14B</figref> for additional details regarding filtering the market scenarios to utilize based on customized market factors. In another embodiment, the market scenarios to utilize also may be filtered based on specified business cycle settings (e.g., as discussed with regard to <figref idref="DRAWINGS">FIG. 27</figref>).

0397Expected security return metrics for the portfolio securities for the filtered market scenarios may be calculated at <b>2165</b>. In one implementation, the expected security return metrics for each constituent security of the portfolio may be determined by iterating through the filtered market scenarios and calculating the expected security return metrics based on the expected returns (e.g., cached) for the filtered market scenarios. For example, the expected return for a constituent security (e.g., MSFT) of the portfolio for the filtered market scenarios may be determined via a MySQL database command similar to the following:

0000<tables id="TABLE-US-00057" num="00057"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>SELECT AVG(linkedScenarioSecurityExpectedReturn) </entry></row><row><entry>FROM ExpectedReturns </entry></row><row><entry>WHERE securityID = “MSFT” AND linkedSimulationID = ID_sim_1 </entry></row><row><entry> AND linkedScenarioID IN (ID_scenario_1, ID_scenario_2, . . . );</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0398Expected portfolio return metrics for the portfolio for the filtered market scenarios may be calculated at <b>2169</b>. In various implementations, the expected portfolio return metrics for the portfolio may be calculated using a weighted average (e.g., weighted based on the portfolio securities weights) of the expected security returns and/or of the calculated expected security return metrics for the constituent securities of the portfolio (e.g., via the API).

0399A visualization of the expected portfolio return metrics for the portfolio and/or of the expected security return metrics for the constituent securities of the portfolio for the filtered market scenarios may be generated at <b>2173</b>. In one implementation, user interface widgets showing the expected portfolio return metrics and/or the expected security return metrics may be generated (e.g., via a portfolio returns visualization response, via a visualization scenario customization output). See <figref idref="DRAWINGS">FIGS. 22-25</figref> for examples of visualizations that may be generated.

0400A determination may be made at <b>2177</b> whether a market factor customization input was obtained from the user (e.g., via a visualization scenario customization input). In one embodiment, the market factor customization input may be a user interface input from the user with a user-specified range of allowable values for an updated market factor. If a market factor customization input was obtained, the specified range of allowable values for the updated market factor may be determined at <b>2181</b>. In one implementation, the visualization scenario customization input may be parsed (e.g., using PHP commands) to determine the specified range of allowable values for the updated market factor (e.g., based on the values of the market_factor_identifier, minimum_range_value, and/or maximum_range_value fields). The set of customized market factors may be updated at <b>2185</b>. In one implementation, a list (e.g., an array of market factor identifiers, a map of market factor identifier values to customized status Boolean values) of customized market factors may be updated. Market scenarios to utilize may be filtered based on the updated set of customized market factors and an updated visualization of the expected portfolio return metrics for the portfolio and/or of the expected security return metrics for the constituent securities of the portfolio may be generated as discussed with regard to <b>2161</b>-<b>2173</b>.

0401<figref idref="DRAWINGS">FIG. 22</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 22</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for generating a portfolio returns visualization for a portfolio is illustrated. Screen <b>2201</b> shows that a user may utilize a scenario tab <b>2205</b> to specify predefined scenario settings. The user may utilize a load predefined scenario widget <b>2210</b> to select a predefined scenario (e.g., from predefined scenarios associated with the user's user identifier) used to filter market scenarios to utilize for generating a portfolio returns visualization.

0402<figref idref="DRAWINGS">FIG. 23</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 23</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for generating a portfolio returns visualization for a portfolio is illustrated. Screen <b>2301</b> shows that the user may utilize market factor widgets (e.g., <b>2305</b>A-B) to view and/or modify ranges of allowable values for each market factor associated with the market scenarios to utilize (e.g., based on customizations specified in the selected predefined scenario). For example, market factor widget <b>2305</b>A shows some exemplary market factors that may be selected by the user for viewing and/or modification.

0403<figref idref="DRAWINGS">FIG. 24</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 24</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for generating a portfolio returns visualization for a portfolio is illustrated. For example, screen <b>2401</b> shows that the user may utilize a market factor widget <b>2405</b>A to view ranges of allowable values (e.g., based on customizations specified in the selected predefined scenario) for the VIX market factor using an allowable range widget <b>2410</b>A, and a market factor widget <b>2405</b>B to view ranges of allowable values (e.g., based on customizations specified in the selected predefined scenario) for the SP500 market factor using an allowable range widget <b>2410</b>B.

0404Screen <b>2401</b> shows that the user may utilize a drawdown widget <b>2425</b> to view the expected loss (e.g., −9.42%) at the worst CVaR percentile outcomes for the portfolio under the original predefined scenario. The user may utilize a return volatility widget <b>2430</b> to view the return volatility (e.g., 4.15%) of the portfolio under the original predefined scenario. The user may utilize a returns distribution widget <b>2435</b> to view the returns distribution of the portfolio under the original predefined scenario. The user may utilize a portfolio securities weights widget <b>2440</b> to view and/or modify portfolio securities weights of individual portfolio securities of the portfolio under the original predefined scenario. The user may utilize a portfolio securities returns widget <b>2445</b> to view expected returns of individual portfolio securities of the portfolio under the original predefined scenario.

0405<figref idref="DRAWINGS">FIG. 25</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 25</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for generating a portfolio returns visualization for a portfolio is illustrated. Screen <b>2501</b> shows that when the user modifies the range of allowable values for a market factor, an updated visualization showing how the expected portfolio return metrics for the portfolio and/or the expected security return metrics for the constituent securities of the portfolio have been affected may be generated. For example, the user may utilize an allowable range widget <b>2510</b>A to modify the range of allowable values (e.g., a customization) for the VIX market factor. The updated visualization shows how the range of allowable values (e.g., shown in an allowable range widget <b>2510</b>B) for the SP500 market factor has been affected (e.g., based on the updated set of filtered market scenarios). The updated visualization shows that the user may utilize a drawdown widget <b>2525</b> to view the expected loss (e.g., −20.25%) at the worst CVaR percentile outcomes for the portfolio under the customized predefined scenario, the expected loss (e.g., −9.42%) at the worst CVaR percentile outcomes for the portfolio under the original predefined scenario, and the difference in the expected loss at the worst CVaR percentile outcomes (e.g., −10.83) between the two scenarios. The updated visualization shows that the user may utilize a return volatility widget <b>2530</b> to view the return volatility (e.g., 4.51%) for the portfolio under the customized predefined scenario, the return volatility (e.g., 4.15%) for the portfolio under the original predefined scenario, and the difference in the expected return volatility (e.g., 0.36%) between the two scenarios. The updated visualization shows that the user may utilize a returns distribution widget <b>2535</b> to view the returns distribution for the portfolio under the customized predefined scenario, the returns distribution for the portfolio under the original predefined scenario, and the difference in the expected returns distribution between the two scenarios. The user may utilize a portfolio securities weights widget <b>2540</b> to view and/or modify portfolio securities weights of individual portfolio securities of the portfolio under the customized predefined scenario. The user may utilize a portfolio securities returns widget <b>2545</b> to view expected returns of individual portfolio securities of the portfolio under the customized predefined scenario. The user may utilize an optimize widget <b>2550</b> to determine an optimized portfolio under the customized predefined scenario (e.g., determined based on the updated set of filtered market scenarios). The user may utilize an execute widget <b>2555</b> to initiate the execution of tradeable buy and/or sell transactions utilized to create the optimized portfolio under the customized predefined scenario.

0406<figref idref="DRAWINGS">FIG. 26</figref> shows a datagraph illustrating data flow(s) for the MLPO. In <figref idref="DRAWINGS">FIG. 26</figref>, dashed lines indicate data flow elements that may be more likely to be optional. In <figref idref="DRAWINGS">FIG. 26</figref>, an user client <b>2604</b> (e.g., of a user) may send a portfolio returns visualization request <b>2621</b> to a MLPO server <b>2606</b> to facilitate generating a portfolio returns visualization based on specified business cycle settings. For example, the user client may be a desktop, a laptop, a tablet, a smartphone, a smartwatch, and/or the like that is executing a client application. In one implementation, the portfolio returns visualization request may include data such as a request identifier, a user identifier, business cycle settings, a simulation model, a pricing date, a portfolio identifier, and/or the like. In one embodiment, the user client may provide the following example portfolio returns visualization request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00058" num="00058"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /portfolio_returns_visualization_request.php HTTP/1.1 </entry></row><row><entry>Host: www.server.com </entry></row><row><entry>Content-Type: Application/XML </entry></row><row><entry>Content-Length: 667 </entry></row><row><entry> </entry></row><row><entry><portfolio_returns_visualization_request> </entry></row><row><entry> <request_identifier>ID_request_41</request_identifier> </entry></row><row><entry> <user_identifier>ID_user_1</user_identifier> </entry></row><row><entry> <business_cycle_settings> </entry></row><row><entry>  <business_cycle> </entry></row><row><entry>   <business_cycle_identifier>ID_CYCLE_LATE</business_cycle_ </entry></row><row><entry>   identifier> </entry></row><row><entry>   <business_cycle_weight>100%</business_cycle_weight> </entry></row><row><entry>  </business_cycle> </entry></row><row><entry> </business_cycle_settings> </entry></row><row><entry> <simulation_model>ID_neural_network_simulation_model_1Y_ </entry></row><row><entry> </simulationmodel></entry></row><row><entry> <pricing_date>2020-04-17</pricing_date> </entry></row><row><entry> <portfolio_identifier>ID_portfolio_1</portfolio_identifier> </entry></row><row><entry></portfolio_returns_visualization_request> </entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0407The MLPO server <b>2606</b> may send an expected returns retrieve request <b>2623</b> to a repository <b>2610</b> to facilitate retrieving expected returns for securities in the portfolio for simulated scenarios corresponding to the specified simulation (e.g., with a simulation identifier determined based on the specified pricing date and/or simulation model). In one implementation, the expected returns retrieve request may include data such as a request identifier, expected returns to retrieve specification, and/or the like. In one embodiment, the MLPO server may provide the following example expected returns retrieve request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00059" num="00059"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /expected_returns_retrieve_request.php HTTP/1.1 </entry></row><row><entry>Host: www.server.com </entry></row><row><entry>Content-Type: Application/XML </entry></row><row><entry>Content-Length: 667 </entry></row><row><entry> </entry></row><row><entry><expected_returns_retrieve_request> </entry></row><row><entry> <request_identifier>ID_request_42</request_identifier> </entry></row><row><entry> <expected_returns_specification> </entry></row><row><entry>  <simulation_identifier>ID_sim_1</simulation_identifier> </entry></row><row><entry>  <scenario> </entry></row><row><entry>   <scenario_identifier>ID_scenario_1</scenario_identifier> </entry></row><row><entry>   <securities>MSFT, AAPL, ...</securities> </entry></row><row><entry>  </scenario> </entry></row><row><entry>  <scenario> </entry></row><row><entry>   <scenario_identifier>ID_scenario_2</scenario_identifier> </entry></row><row><entry>   <securities>MSFT, AAPL, ...</securities> </entry></row><row><entry>  </scenario> </entry></row><row><entry>  ... </entry></row><row><entry> </expected_returns_specification> </entry></row><row><entry></expected_returns_retrieve_request> </entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0408The repository <b>2610</b> may send an expected returns retrieve response <b>2629</b> to the MLPO server <b>2606</b> with the requested expected returns data. In one implementation, the expected returns retrieve response may include data such as a response identifier, the requested expected returns data, and/or the like. In one embodiment, the repository may provide the following example expected returns retrieve response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00060" num="00060"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /expected_returns_retrieve_response.php HTTP/1.1 </entry></row><row><entry>Host: www.server.com </entry></row><row><entry>Content-Type: Application/XML </entry></row><row><entry>Content-Length: 667 </entry></row><row><entry> </entry></row><row><entry><expected_returns_retrieve_response> </entry></row><row><entry> <response_identifier>ID_response_42</response_identifier> </entry></row><row><entry> <expected_returns> </entry></row><row><entry>  <scenario> </entry></row><row><entry>   <scenario_identifier>ID_scenario_1</scenario_identifier> </entry></row><row><entry>   <security> </entry></row><row><entry>    <security_identifier>MSFT</security_identifier> </entry></row><row><entry>    <expected_return>10%</expected_return> </entry></row><row><entry>   </security> </entry></row><row><entry>   <security> </entry></row><row><entry>    <security_identifier>AAPL</security_identifier> </entry></row><row><entry>    <expected_return>12%</expected_return> </entry></row><row><entry>   </security> </entry></row><row><entry>   ... </entry></row><row><entry>  </scenario> </entry></row><row><entry>  <scenario> </entry></row><row><entry>   <scenario_identifier>ID_scenario_2</scenario_identifier> </entry></row><row><entry>   <security> </entry></row><row><entry>    <security_identifier>MSFT</security_identifier> </entry></row><row><entry>    <expected_return>15%</expected_return> </entry></row><row><entry>   </security> </entry></row><row><entry>   <security> </entry></row><row><entry>    <security_identifier>AAPL</security_identifier> </entry></row><row><entry>    <expected_return>13%</expected_return> </entry></row><row><entry>   </security> </entry></row><row><entry>   ... </entry></row><row><entry>  </scenario> </entry></row><row><entry>  ... </entry></row><row><entry> </expected_returns> </entry></row><row><entry></expected_returns_retrieve_response> </entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0409A business cycle based portfolio returns visualizing (BPRV) component <b>2633</b> may utilize data provided in the portfolio returns visualization request to generate a portfolio return metrics visualization. See <figref idref="DRAWINGS">FIG. 27</figref> for additional details regarding the BPRV component.

0410The MLPO server <b>2606</b> may send a portfolio returns visualization response <b>2637</b> to the user client <b>2604</b> to provide a visualization of portfolio return metrics for the specified portfolio under the specified business cycle settings. In one implementation, the portfolio returns visualization response may include data such as a response identifier, visualization data, and/or the like. In one embodiment, the MLPO server may provide the following example portfolio returns visualization response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00061" num="00061"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /portfolio_returns_visualization_response.php HTTP/1.1 </entry></row><row><entry>Host: www.server.com </entry></row><row><entry>Content-Type: Application/XML </entry></row><row><entry>Content-Length: 667 </entry></row><row><entry> </entry></row><row><entry><portfolio_returns_visualization_response> </entry></row><row><entry> <response_identifier>ID_response_41</response_identifier> </entry></row><row><entry> <visualization_data> </entry></row><row><entry>  portfolio return metrics data (e.g., constituent securities' and/or </entry></row><row><entry>  portfolio's returns, worst returns, return volatility, frequency vs. </entry></row><row><entry>  returns data) </entry></row><row><entry> </visualization_data> </entry></row><row><entry></portfolio_returns_visualization_response> </entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0411If the user customizes business cycle settings, the user client <b>2604</b> may send a visualization business cycle customization input <b>2641</b> to the MLPO server <b>2606</b> specifying updated business cycle settings. In one implementation, the visualization business cycle customization input may include data such as a request identifier, business cycle settings, and/or the like. In one embodiment, the user client may provide the following example visualization business cycle customization input, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00062" num="00062"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /visualization_business_cycle_customization_input.php HTTP/1.1 </entry></row><row><entry>Host: www.server.com </entry></row><row><entry>Content-Type: Application/XML </entry></row><row><entry>Content-Length: 667 </entry></row><row><entry> </entry></row><row><entry><visualization_business_cycle_customization_input> </entry></row><row><entry> <request_identifier>ID_request_43</request_identifier> </entry></row><row><entry> <business_cycle_settings> </entry></row><row><entry>  <business_cycle> </entry></row><row><entry>   <business_cycle_identifier>ID_CYCLE_LATE</business_cycle_identifier> </entry></row><row><entry>   <business_cycle_weight>85%</business_cycle_weight> </entry></row><row><entry>  </business_cycle> </entry></row><row><entry>  <business_cycle> </entry></row><row><entry>   <business_cycle_identifier>ID_CYCLE_RECESSION</business_cycle_identifier> </entry></row><row><entry>   <business_cycle_weight>15%</business_cycle_weight> </entry></row><row><entry>  </business_cycle> </entry></row><row><entry> </business_cycle_settings> </entry></row><row><entry></visualization_business_cycle_customization_input> </entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0412The MLPO server <b>2606</b> may send a visualization business cycle customization output <b>2645</b> to the user client <b>2604</b> to provide an updated visualization of portfolio return metrics for the specified portfolio (e.g., under the modified business cycle settings). In one implementation, the visualization business cycle customization output may include data such as a response identifier, visualization data, and/or the like. In one embodiment, the MLPO server may provide the following example visualization business cycle customization output, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00063" num="00063"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /visualization_business_cycle_customization_output.php HTTP/1.1 </entry></row><row><entry>Host: www.server.com </entry></row><row><entry>Content-Type: Application/XML </entry></row><row><entry>Content-Length: 667 </entry></row><row><entry> </entry></row><row><entry><visualization_business_cycle_customization_output> </entry></row><row><entry> <response_identifier>ID_response_43</response_identifier> </entry></row><row><entry> <visualization_data> </entry></row><row><entry>  portfolio return metrics data (e.g., constituent securities' and/or </entry></row><row><entry>  portfolio's returns, worst returns, return volatility, frequency vs. </entry></row><row><entry>  returns data) </entry></row><row><entry> </visualization_data> </entry></row><row><entry></visualization_business_cycle_customization_output> </entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0413<figref idref="DRAWINGS">FIG. 27</figref> shows a logic flow illustrating embodiments of a business cycle based portfolio returns visualizing (BPRV) component for the MLPO. In <figref idref="DRAWINGS">FIG. 27</figref>, a portfolio returns visualization request may be obtained at <b>2701</b>. For example, the portfolio returns visualization request may be obtained as a result of a user requesting generation of a portfolio returns visualization.

0414Market scenarios to utilize for generating the portfolio returns visualization may be determined at <b>2705</b>. In one embodiment, the market scenarios to utilize may be determined based on the simulation model (e.g., for a specified pricing date) and/or time period length selected by the user. In another embodiment, the market scenarios to utilize may be determined based on filters applied to simulated market scenarios. In one implementation, the portfolio returns visualization request may be parsed (e.g., using PHP commands) to determine the market scenarios to utilize (e.g., based on the values of the simulation_model and/or pricing_date fields). For example, the selected simulation model and/or pricing date may be used to determine a simulation identifier (e.g., ID_sim_1) of the corresponding simulation (e.g., a set of simulated market scenarios).

0415Portfolio securities of a portfolio may be determined at <b>2709</b> and portfolio securities weights for the portfolio securities may be determined at <b>2713</b>. In one embodiment, the portfolio securities and/or the corresponding portfolio securities weights may be retrieved from a database (e.g., based on a portfolio identifier). In one implementation, the portfolio returns visualization request may be parsed (e.g., using PHP commands) to determine the portfolio identifier (e.g., based on the value of the portfolio_identifier field). In another embodiment, the portfolio securities and/or the corresponding portfolio securities weights may be specified by the user. In one implementation, the portfolio returns visualization request may be parsed (e.g., using PHP commands) to determine the specified portfolio securities and/or the corresponding portfolio securities weights. In another embodiment, the portfolio securities and/or the corresponding portfolio securities weights may be determined based on an optimization. In one implementation, the portfolio securities and/or the corresponding portfolio securities weights may be determined as discussed with regard to the PC component.

0416Expected returns of the portfolio securities for the market scenarios to utilize may be retrieved from a database at <b>2717</b>. For example, the expected returns may be cached to facilitate expected return metrics calculations. In one implementation, the expected returns may be retrieved via an expected returns retrieve request.

0417A determination may be made at <b>2721</b> whether there remain portfolio securities to process. In one implementation, each of the constituent portfolio securities may be processed. If there remain portfolio securities to process, the next security (e.g., with identifier MSFT) may be selected for processing at <b>2725</b>.

0418A determination may be made at <b>2729</b> whether there remain market scenarios to analyze. In one implementation, each of the market scenarios to utilize may be analyzed. If there remain market scenarios to analyze, the next market scenario (e.g., with identifier ID_scenario_1) may be selected for analysis at <b>2733</b>.

0419An expected return for the selected security for the selected market scenario may be determined at <b>2737</b>. In one implementation, the expected return may be retrieved from cache. In another implementation, the expected return may be retrieved from a database. For example, the expected return for the selected security for the selected market scenario may be determined via a MySQL database command similar to the following:

0000<tables id="TABLE-US-00064" num="00064"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>SELECT linkedScenarioSecurityExpectedReturn </entry></row><row><entry>FROM ExpectedReturns </entry></row><row><entry>WHERE securityID = “MSFT” AND linkedSimulationID = ID_sim_1 </entry></row><row><entry>AND </entry></row><row><entry> linkedScenarioID = ID_scenario_1;</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0420Expected security return metrics for the selected security for the market scenarios to utilize may be calculated at <b>2741</b>. For example, the expected security return metrics for a security may include the security's expected return, worst returns, return volatility, frequency vs. returns data, and/or the like. In one implementation, the expected security return metrics for each security may be determined by iterating through the market scenarios to utilize and calculating the expected security return metrics based on the expected returns (e.g., cached) for the market scenarios to utilize. For example, the expected return for the selected security for the market scenarios to utilize may be determined via a MySQL database command similar to the following:

0000<tables id="TABLE-US-00065" num="00065"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>SELECT AVG(linkedScenarioSecurityExpectedReturn) </entry></row><row><entry>FROM ExpectedReturns </entry></row><row><entry>WHERE securityID = “MSFT” AND linkedSimulationID = ID_sim_1;</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0421Expected portfolio return metrics for the portfolio for the market scenarios to utilize may be calculated at <b>2745</b>. For example, the expected portfolio return metrics for a portfolio may include the portfolio's expected return, worst returns, return volatility, frequency vs. returns data, and/or the like. In various implementations, the expected portfolio return metrics for the portfolio may be calculated using a weighted average (e.g., weighted based on the portfolio securities weights) of the expected security returns and/or of the calculated expected security return metrics for the constituent securities of the portfolio. For example, the following API may be utilized to determine the expected portfolio return metrics for the portfolio for the market scenarios to utilize:

0422POST API/RUNANALYSIS <ul id="ul0040" list-style="none"><li id="ul0040-0001" num="0000"><ul id="ul0041" list-style="none"><li id="ul0041-0001" num="0423">This API facilitates generating portfolio return metrics visualization for a specified portfolio (e.g., list of securities). The portfolio return metrics calculation results are included in the Summary object returned by the API.</li><li id="ul0041-0002" num="0424">The API returns HTTP/1.1 status code 201 if the request is successful. It returns 500 Internal Server Error if there is an exception.</li></ul></li></ul>

0425Input Parameter Details

0000<tables id="TABLE-US-00066" num="00066"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="28pt" align="left" /><colspec colname="4" colwidth="91pt" align="left" /><thead><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>Attribute name</entry><entry>Mandatory</entry><entry>Default</entry><entry>Description/Rule</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>securityInputs</entry><entry>Y</entry><entry /><entry>Specify the initial</entry></row><row><entry /><entry /><entry /><entry>investment</entry></row><row><entry>cash</entry><entry>N</entry><entry>0</entry><entry>Integer between 1 and 50</entry></row><row><entry>modelId</entry><entry>Y</entry><entry>1</entry><entry>Integer, either 1 or 4</entry></row><row><entry /><entry /><entry /><entry>based on the model</entry></row><row><entry>simulationId</entry><entry>Y</entry><entry>0</entry><entry>Taxable = 1, Tax-Exempt = 0</entry></row><row><entry>simulationInputs</entry><entry>Y</entry><entry /><entry>List of factor min and max</entry></row><row><entry /><entry /><entry /><entry>range for filtering of</entry></row><row><entry /><entry /><entry /><entry>scenarios</entry></row><row><entry>businessCycleInputs</entry><entry>N</entry><entry /><entry>List of business cycle</entry></row><row><entry /><entry /><entry /><entry>inputs and associated</entry></row><row><entry /><entry /><entry /><entry>percentages. (e.g., Late</entry></row><row><entry /><entry /><entry /><entry>Cycle 50% and Recession</entry></row><row><entry /><entry /><entry /><entry>50%)</entry></row><row><entry>pricingDt</entry><entry>Y</entry><entry /><entry>Current Pricing Date for</entry></row><row><entry /><entry /><entry /><entry>which simulation data is</entry></row><row><entry /><entry /><entry /><entry>available</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00067" num="00067"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>REQUEST</entry></row><row><entry>POST API/runAnalysis </entry></row><row><entry>Content-type: application/json </entry></row><row><entry>{</entry></row><row><entry>  ″securityInputs″: [{</entry></row><row><entry>         “fmrCusip”: “EAFE”, </entry></row><row><entry>         “description”:”EAFE”, </entry></row><row><entry>         “qty”: 200000 </entry></row><row><entry>      }, {</entry></row><row><entry>         “fmrCusip”: “DHI270000”, </entry></row><row><entry>         “description”: ″USTB 3.375% 11/15/48″, </entry></row><row><entry>         “qty”: 200000 </entry></row><row><entry>      }</entry></row><row><entry>      ... . </entry></row><row><entry>  ], </entry></row><row><entry>  ″cash″: 0, </entry></row><row><entry>  ″modelId″: 1, </entry></row><row><entry>  ″simulationId″: 1, </entry></row><row><entry>  ″pricingDt″: “01/01/2020”, </entry></row><row><entry>  ″simulationInputs”:[{</entry></row><row><entry>          “factorName”: ″VIX″, </entry></row><row><entry>          “rangeStart”: −3544, </entry></row><row><entry>          “rangeEnd”: 5513 </entry></row><row><entry>       }, {</entry></row><row><entry>          “factorName”: ″SP500″, </entry></row><row><entry>          “rangeStart”: −4648, </entry></row><row><entry>          “rangeEnd”: 2947}</entry></row><row><entry>   ], </entry></row><row><entry>  ″businessCycleInputs″: [{</entry></row><row><entry>           cycleName: ″Late″, </entry></row><row><entry>           percentage: 100 </entry></row><row><entry>        }, {</entry></row><row><entry>           cycleName: ″Recession″, </entry></row><row><entry>           percentage: 0 </entry></row><row><entry>     }] </entry></row><row><entry> ... </entry></row><row><entry>}</entry></row><row><entry>RESPONSE</entry></row><row><entry>201 </entry></row><row><entry>Content-Type: application/json </entry></row><row><entry>{</entry></row><row><entry>  ″summary″: {</entry></row><row><entry>         “risk”: 234.42. </entry></row><row><entry>         “avg5Percentile”: −202.09 </entry></row><row><entry>     }, </entry></row><row><entry>  “marketReturns”:[   {</entry></row><row><entry>         ″marketId″: 959, </entry></row><row><entry>         ″bucketId″: 4, </entry></row><row><entry>         ″marketReturn″: −434.16 </entry></row><row><entry>       }, {</entry></row><row><entry>         ″marketId″: 2527, </entry></row><row><entry>         ″bucketId″: 6, </entry></row><row><entry>         ″marketReturn″: −252.16 </entry></row><row><entry>       }, </entry></row><row><entry>        ... </entry></row><row><entry>    ] </entry></row><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0426A visualization of the expected portfolio return metrics for the portfolio and/or of the expected security return metrics for the constituent securities of the portfolio for the market scenarios to utilize may be generated at <b>2749</b>. In one implementation, user interface widgets showing the expected portfolio return metrics and/or the expected security return metrics may be generated via a portfolio returns visualization response. See <figref idref="DRAWINGS">FIGS. 28-30</figref> for examples of visualizations that may be generated.

0427A determination may be made at <b>2753</b> whether a business cycle selection input was obtained from the user. In one embodiment, the business cycle selection input may be a user interface input from the user with a user-specified business cycle selection. For example, the user may select a business cycle (e.g., using a user interface widget to select a specific business cycle, using a user interface widget to request that the MLPO determine the appropriate business cycle (e.g., the business cycle under which the portfolio has the best or the worst expected return metrics)) to determine how expected portfolio return metrics for the portfolio and/or for the constituent securities of the portfolio would change given occurrence of the business cycle (e.g., during the investment time period). In another example, the user may select multiple business cycles, and an associated weight (e.g., probability of occurrence) for each business cycle, to determine how expected portfolio return metrics for the portfolio and/or for the constituent securities of the portfolio would change given business cycle expectations (e.g., during the investment time period).

0428If a business cycle selection input was obtained, the specified set of business cycles and/or associated business cycle weights may be determined at <b>2755</b>. In one implementation, the set of business cycles and/or the associated business cycle weights may be specified in a visualization business cycle customization input, and the visualization business cycle customization input may be parsed (e.g., using PHP commands) to determine the specified set of business cycles and/or the associated business cycle weights (e.g., based on the values of the business_cycle_identifier and/or business_cycle_weight fields).

0429A determination may be made at <b>2757</b> whether there remain business cycles to process. In one implementation, each of the specified business cycles may be processed. If there remain business cycles to process, the next business cycle may be selected for processing at <b>2759</b>.

0430The market scenarios to utilize may be filtered based on the selected business cycle at <b>2761</b>. In one embodiment, the market scenarios to utilize may be filtered to the subset of market scenarios that are associated with the selected business cycle. In one implementation, each market scenario to utilize may be associated with a business cycle identifier (e.g., indicating a business cycle during which a simulated market scenario would have occurred), and market scenarios to utilize whose business cycle identifiers do not match the business cycle identifier of the selected business cycle may be filtered out. In another embodiment, the market scenarios to utilize also may be filtered based on specified customized market factors (e.g., as discussed with regard to <figref idref="DRAWINGS">FIG. 21</figref>).

0431Expected security return metrics for the portfolio securities for the filtered market scenarios may be calculated at <b>2765</b>. In one implementation, the expected security return metrics for each constituent security of the portfolio for the selected business cycle may be determined by iterating through the filtered market scenarios and calculating the expected security return metrics based on the expected returns (e.g., cached) for the filtered market scenarios. For example, the expected return for a constituent security (e.g., MSFT) of the portfolio for the filtered market scenarios may be determined via a MySQL database command similar to the following: <ul id="ul0042" list-style="none"><li id="ul0042-0001" num="0000"><ul id="ul0043" list-style="none"><li id="ul0043-0001" num="0432">SELECT AVG(linkedScenarioSecurityExpectedReturn)</li><li id="ul0043-0002" num="0433">FROM ExpectedReturns</li><li id="ul0043-0003" num="0434">WHERE securityID=“MSFT” AND linkedSimulationID=ID_sim_1 AND <ul id="ul0044" list-style="none"><li id="ul0044-0001" num="0435">linkedScenarioID IN (ID_scenario_1, ID_scenario_2, . . . );</li></ul></li></ul></li></ul>

0436Expected portfolio return metrics for the portfolio for the filtered market scenarios may be calculated at <b>2769</b>. In various implementations, the expected portfolio return metrics for the portfolio for the selected business cycle may be calculated using a weighted average (e.g., weighted based on the portfolio securities weights) of the expected security returns and/or of the calculated expected security return metrics for the constituent securities of the portfolio (e.g., via the API) for the selected business cycle.

0437Once the specified business cycles have been processed, weighted expected security return metrics for the portfolio securities for the specified business cycles may be calculated at <b>2773</b>. For example, the weighted expected security return metrics for a security may include the security's weighted expected return, worst returns, return volatility, frequency vs. returns data, and/or the like. In various implementations, the weighted expected security return metrics for a constituent security for the specified business cycles may be calculated using a weighted average (e.g., weighted based on the associated business cycle weights) of the expected security returns for the constituent security for each of the specified business cycles and/or of the calculated expected security return metrics for the constituent security for each of the specified business cycles.

0438Weighted expected portfolio return metrics for the portfolio for the specified business cycles may be calculated at <b>2777</b>. For example, the weighted expected portfolio return metrics for a portfolio may include the portfolio's weighted expected return, worst returns, return volatility, frequency vs. returns data, and/or the like. In various implementations, the weighted expected portfolio return metrics for the portfolio for the specified business cycles may be calculated using a weighted average (e.g., weighted based on the portfolio securities weights) of the calculated weighted expected security return metrics for the constituent securities of the portfolio and/or using a weighted average (e.g., weighted based on the associated business cycle weights) of the calculated expected portfolio return metrics for the portfolio for each of the specified business cycles (e.g., via the API).

0439A visualization of the weighted expected portfolio return metrics for the portfolio and/or of the weighted expected security return metrics for the constituent securities of the portfolio for the specified business cycles may be generated at <b>2781</b>. In one implementation, user interface widgets showing the weighted expected portfolio return metrics and/or the weighted expected security return metrics may be generated (e.g., via a portfolio returns visualization response, via a visualization business cycle customization output). See <figref idref="DRAWINGS">FIGS. 28-30</figref> for examples of visualizations that may be generated.

0440A determination may be made at <b>2785</b> whether a business cycle weight selection input was obtained from the user (e.g., via a visualization business cycle customization input). In one embodiment, the business cycle weight selection input may be a user interface input from the user with user-specified business cycle weights for the specified business cycles. If a business cycle weight selection input was obtained, the specified business cycle weights for the specified business cycles may be updated at <b>2789</b>. In one implementation, the visualization business cycle customization input may be parsed (e.g., using PHP commands) to determine the updated business cycle weights (e.g., based on the values of the business_cycle_weight fields). A determination may be made at <b>2793</b> whether the expected portfolio return metrics for the portfolio for each of the specified business cycles and/or the expected security return metrics for the constituent securities of the portfolio for each of the specified business cycles are cached (e.g., from a previous calculation that used different business cycle weights for the specified business cycles). If cached, an updated visualization of the weighted expected portfolio return metrics for the portfolio and/or of the weighted expected security return metrics for the constituent securities of the portfolio for the specified business cycles may be generated as discussed with regard to <b>2773</b>-<b>2781</b>. If not cached, an updated visualization of the weighted expected portfolio return metrics for the portfolio and/or of the weighted expected security return metrics for the constituent securities of the portfolio for the specified business cycles may be generated as discussed with regard to <b>2757</b>-<b>2781</b>.

0441<figref idref="DRAWINGS">FIG. 28</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 28</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for generating a portfolio returns visualization for a portfolio is illustrated. Screen <b>2801</b> shows that a user may utilize a business cycle tab <b>2803</b> to specify business cycle settings. The user may utilize business cycle selection widgets <b>2805</b>A-B to specify business cycles to utilize. For example, business cycle selection widget <b>2805</b>A shows some exemplary business cycles that may be selected by the user. The user may utilize business cycle weight selection widgets <b>2810</b>A-B to specify business cycle weights to utilize. For example, the user may specify that a portfolio returns visualization should be generated based on an expectation that the Late business cycle (e.g., selected using business cycle selection widget <b>2805</b>A) is going to occur with 100% probability (e.g., selected using business cycle weight selection widget <b>2810</b>A). The user may utilize a positioning widget <b>2815</b> to request that the MLPO determine the appropriate business cycle. For example, the user may specify that a portfolio returns visualization should be generated for the business cycle under which the portfolio has the best expected returns (e.g., Late business cycle).

0442Screen <b>2801</b> shows that the user may utilize a returns distribution widget <b>2835</b> to view the returns distribution of the portfolio under the original business cycle settings. The user may utilize a portfolio securities weights widget <b>2840</b> to view and/or modify portfolio securities weights of individual portfolio securities of the portfolio under the original business cycle settings. The user may utilize a portfolio securities returns widget <b>2845</b> to view expected returns of individual portfolio securities of the portfolio under the original business cycle settings.

0443<figref idref="DRAWINGS">FIG. 29</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 29</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for generating a portfolio returns visualization for a portfolio is illustrated. Screen <b>2901</b> shows that when the user modifies the business cycle settings an updated visualization showing how the expected portfolio return metrics for the portfolio and/or the expected security return metrics for the constituent securities of the portfolio have been affected may be generated. For example, the user may specify that the updated portfolio returns visualization should be generated based on an expectation (e.g., a customization) that the Late business cycle (e.g., selected using business cycle selection widget <b>2905</b>A) is going to occur with 85% probability (e.g., selected using business cycle weight selection widget <b>2910</b>A) and the Recession business cycle (e.g., selected using business cycle selection widget <b>2905</b>B) is going to occur with 15% probability (e.g., selected using business cycle weight selection widget <b>2910</b>B). The updated visualization shows that the user may utilize a drawdown widget <b>2925</b> to view the expected loss (e.g., −1.30%) at the worst CVaR percentile outcomes for the portfolio under the customized business cycle settings, the expected loss (e.g., −0.99%) at the worst CVaR percentile outcomes for the portfolio under the original business cycle settings, and the difference in the expected loss at the worst CVaR percentile outcomes (e.g., −0.31) between the two business cycle settings. The updated visualization shows that the user may utilize a return volatility widget <b>2930</b> to view the return volatility (e.g., 0.55%) for the portfolio under the customized business cycle settings, the return volatility (e.g., 0.40%) for the portfolio under the original business cycle settings, and the difference in the expected return volatility (e.g., 0.15%) between the two business cycle settings. The updated visualization shows that the user may utilize a returns distribution widget <b>2935</b> to view the returns distribution for the portfolio under the customized business cycle settings, the returns distribution for the portfolio under the original business cycle settings, and the difference in the expected returns distribution between the two business cycle settings. The user may utilize a portfolio securities weights widget <b>2940</b> to view and/or modify portfolio securities weights of individual portfolio securities of the portfolio under the customized business cycle settings. The user may utilize a portfolio securities returns widget <b>2945</b> to view expected returns of individual portfolio securities of the portfolio under the customized business cycle settings. The user may utilize an optimize widget <b>2950</b> to determine an optimized portfolio under the customized business cycle settings (e.g., determined based on the updated weighted expected security returns for the constituent securities of the portfolio). The user may utilize an execute widget <b>2955</b> to initiate the execution of tradeable buy and/or sell transactions utilized to create the optimized portfolio under the customized business cycle settings.

0444<figref idref="DRAWINGS">FIG. 30</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 30</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for generating a portfolio returns visualization for a portfolio is illustrated. Screen <b>3001</b> shows that the user may utilize a positioning widget <b>3015</b> to request that the MLPO determine the appropriate business cycle. For example, the user may specify that a portfolio returns visualization should be generated for the business cycle (e.g., a customization) under which the portfolio has the worst expected returns (e.g., Early business cycle (e.g., as shown by business cycle selection widgets <b>3005</b>A-B) with 100% probability (e.g., as shown by business cycle weight selection widgets <b>3010</b>A-B)). The updated visualization shows that the user may utilize a drawdown widget <b>3025</b> to view the expected loss (e.g., −1.19%) at the worst CVaR percentile outcomes for the portfolio under the customized business cycle settings, the expected loss (e.g., −0.99%) at the worst CVaR percentile outcomes for the portfolio under the original business cycle settings, and the difference in the expected loss at the worst CVaR percentile outcomes (e.g., −0.20) between the two business cycle settings. The updated visualization shows that the user may utilize a return volatility widget <b>3030</b> to view the return volatility (e.g., 0.45%) for the portfolio under the customized business cycle settings, the return volatility (e.g., 0.40%) for the portfolio under the original business cycle settings, and the difference in the expected return volatility (e.g., 0.05%) between the two business cycle settings. The updated visualization shows that the user may utilize a returns distribution widget <b>3035</b> to view the returns distribution for the portfolio under the customized business cycle settings, the returns distribution for the portfolio under the original business cycle settings, and the difference in the expected returns distribution between the two business cycle settings. The user may utilize a portfolio securities weights widget <b>3040</b> to view and/or modify portfolio securities weights of individual portfolio securities of the portfolio under the customized business cycle settings. The user may utilize a portfolio securities returns widget <b>3045</b> to view expected returns of individual portfolio securities of the portfolio under the customized business cycle settings.

0445<figref idref="DRAWINGS">FIG. 34</figref> shows a datagraph illustrating data flow(s) for the MLPO. In <figref idref="DRAWINGS">FIG. 34</figref>, a client <b>3402</b> (e.g., of a user) may send a portfolio returns visualization request <b>3421</b> to an application server <b>3406</b> to facilitate generating a portfolio returns visualization (e.g., based on customized market factors as discussed with regard to <figref idref="DRAWINGS">FIG. 20</figref>, based on specified business cycle settings as discussed with regard to <figref idref="DRAWINGS">FIG. 26</figref>, for constructing an optimized bond ladder portfolio as discussed with regard to <figref idref="DRAWINGS">FIG. 37</figref>). For example, the client may be a desktop, a laptop, a tablet, a smartphone, a smartwatch, and/or the like that is executing a client application. In one implementation, the portfolio returns visualization request may include data such as a request identifier, a user identifier, a predefined scenario identifier, business cycle settings, a simulation model, a pricing date, a portfolio identifier, investment securities settings, and/or the like. In one embodiment, the client may provide the following example portfolio returns visualization request, substantially in the form of a (Secure) Hypertext Transfer Protocol (“HTTP(S)”) POST message including eXtensible Markup Language (“XML”) formatted data, as provided below:

0000<tables id="TABLE-US-00068" num="00068"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>POST /portfolio_returns_visualization_request.php HTTP/1.1 </entry></row><row><entry /><entry>Host: www.server.com </entry></row><row><entry /><entry>Content-Type: Application/XML </entry></row><row><entry /><entry>Content-Length: 667 </entry></row><row><entry /><entry> </entry></row><row><entry /><entry><portfolio_returns_visualization_request> </entry></row><row><entry /><entry> <request_identifier>ID_request_51</request_identifier> </entry></row><row><entry /><entry> <user_identifier>ID_user_1</user_identifier> </entry></row><row><entry /><entry> <simulation_model>ID_neural_network_simulation_model_1Y </entry></row><row><entry /><entry> </simulation_model></entry></row><row><entry /><entry> <pricing_date>2020-04-17</pricing_date> </entry></row><row><entry /><entry> <portfolio_identifier>ID_portfolio_1</portfolio_identifier> </entry></row><row><entry /><entry> ... </entry></row><row><entry /><entry></portfolio_returns_visualization_request> </entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0446A portfolio returns visualizing (PRV) component <b>3425</b> may utilize data provided in the portfolio returns visualization request to generate a portfolio return metrics visualization based on asset return metrics provided by a database calculation engine. In some embodiments, the PRV component may be an optimized version of the SPRV component (e.g., discussed with regard to <figref idref="DRAWINGS">FIG. 21</figref>), BPRV component (e.g., discussed with regard to <figref idref="DRAWINGS">FIG. 27</figref>), and/or the like components (e.g., a component used to implement a bond ladder construction process discussed with regard to <figref idref="DRAWINGS">FIG. 48</figref>) that utilizes the database calculation engine for improved performance. See <figref idref="DRAWINGS">FIG. 35</figref> for additional details regarding the PRV component.

0447The application server <b>3406</b> may send an asset return metrics calculation request <b>3429</b> to a database server <b>3410</b> to obtain asset return metrics for securities in the portfolio for simulated scenarios corresponding to the specified simulation (e.g., with a simulation identifier determined based on the specified pricing date and/or simulation model). In one implementation, the asset return metrics calculation request may include data such as a request identifier, asset return metrics to retrieve specification, and/or the like. In one embodiment, the application server may provide the following example asset return metrics calculation request, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00069" num="00069"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>POST /asset_return_metrics_calculation_request.php HTTP/1.1 </entry></row><row><entry /><entry>Host: www.server.com </entry></row><row><entry /><entry>Content-Type: Application/XML </entry></row><row><entry /><entry>Content-Length: 667 </entry></row><row><entry /><entry> </entry></row><row><entry /><entry><asset_return_metrics_calculation_request> </entry></row><row><entry /><entry> <request_identifier>ID_request_52</request_identifier> </entry></row><row><entry /><entry> <securities>MSFT, AAPL, ...</securities> </entry></row><row><entry /><entry> <simulation_identifier>ID_sim_1</simulation_identifier> </entry></row><row><entry /><entry> <pricing_date>2020-04-17</pricing_date> </entry></row><row><entry /><entry> <requested_asset_return_metrics> </entry></row><row><entry /><entry>  ID_METRIC_EXPECTED_RETURN, ID_METRIC_CVAR </entry></row><row><entry /><entry> </requested_asset_return_metrics> </entry></row><row><entry /><entry></asset_return_metrics_calculation_request> </entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0448An asset return metrics calculating (ARMC) component <b>3433</b> may utilize data provided in the asset return metrics calculation request to calculate asset return metrics for securities in the portfolio. See <figref idref="DRAWINGS">FIG. 36</figref> for additional details regarding the ARMC component.

0449The database server <b>3410</b> may send an asset return metrics calculation response <b>3437</b> to the application server <b>3406</b> with the requested asset return metrics data. In one implementation, the asset return metrics calculation response may include data such as a response identifier, the requested asset return metrics data, and/or the like. In one embodiment, the database server may provide the following example asset return metrics calculation response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00070" num="00070"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /asset_return_metrics_calculation_response.php HTTP/1.1 </entry></row><row><entry>Host: www.server.com </entry></row><row><entry>Content-Type: Application/XML </entry></row><row><entry>Content-Length: 667 </entry></row><row><entry> </entry></row><row><entry><asset_return_metrics_calculation_response> </entry></row><row><entry> <response_identifier>ID_response_52</response_identifier> </entry></row><row><entry> <asset_simulation_wide_table_data> </entry></row><row><entry>  <record> </entry></row><row><entry>   <asset_id>IBM</asset_id> </entry></row><row><entry>   <pricing_date>2020-04-17</pricing_date> </entry></row><row><entry>   <simulation_identifier>ID_sim_1</simulation_identifier> </entry></row><row><entry>   <returns>354,353,369,...</returns> </entry></row><row><entry>  </record> </entry></row><row><entry>  <record> </entry></row><row><entry>   <asset_id>AAPL</asset_id> </entry></row><row><entry>   <pricing_date>2020-04-17</pricing_date> </entry></row><row><entry>   <simulation_identifier>ID_sim_1</simulation_identifier> </entry></row><row><entry>   <returns>384,430,276,...</returns> </entry></row><row><entry>  </record> </entry></row><row><entry>  ... </entry></row><row><entry> </asset_simulation_wide_table_data> </entry></row><row><entry> <asset_measure_table_data> </entry></row><row><entry>  <record> </entry></row><row><entry>   <asset_id>IBM</asset_id> </entry></row><row><entry>   <pricing_date>2020-04-17</pricing_date> </entry></row><row><entry>   <simulation_identifier>ID_sim_1</simulation_identifier> </entry></row><row><entry>   <scenario_identifier>ID_scenario_1</scenario_identifier> </entry></row><row><entry>   <metric_identifier>ID_METRIC_EXPECTED_RETURN</metric_identifier> </entry></row><row><entry>   <metric_value>354</metric_value> </entry></row><row><entry>  </record> </entry></row><row><entry>  <record> </entry></row><row><entry>   <asset_id>IBM</asset_id> </entry></row><row><entry>   <pricing_date>2020-04-17</pricing_date> </entry></row><row><entry>   <simulation_identifier>ID_sim_1</simulation_identifier> </entry></row><row><entry>   <scenario_identifier>ID_scenario_2</scenario_identifier> </entry></row><row><entry>   <metric_identifier>ID_METRIC_EXPECTED_RETURN</metric_identifier> </entry></row><row><entry>   <metric_value>353</metric_value> </entry></row><row><entry>  </record> </entry></row><row><entry>  ... </entry></row><row><entry>  <record> </entry></row><row><entry>   <asset_id>IBM</asset_id> </entry></row><row><entry>   <pricing_date>2020-04-17</pricing_date> </entry></row><row><entry>   <simulation_identifier>ID_sim_1</simulation_identifier> </entry></row><row><entry>   <scenario_identifier>ID_scenario_1</scenario_identifier> </entry></row><row><entry>   <metric_identifier>ID_METRIC_CVAR</metric_identifier> </entry></row><row><entry>   <metric_value>−8.05%</metric_value> </entry></row><row><entry>  </record> </entry></row><row><entry>  <record> </entry></row><row><entry>   <asset_id>IBM</asset_id> </entry></row><row><entry>   <pricing_date>2020-04-17</pricing_date> </entry></row><row><entry>   <simulation_identifier>ID_sim_1</simulation_identifier> </entry></row><row><entry>   <scenario_identifier>ID_scenario_2</scenario_identifier> </entry></row><row><entry>   <metric_identifier>ID_METRIC_CVAR</metric_identifier> </entry></row><row><entry>   <metric_value>−9.15%</metric_value> </entry></row><row><entry>  </record> </entry></row><row><entry>  ... </entry></row><row><entry>  <record> </entry></row><row><entry>   <asset_id>AAPL</asset_id> </entry></row><row><entry>   <pricing_date>2020-04-17</pricing_date> </entry></row><row><entry>   <simulation_identifier>ID_sim_1</simulation_identifier> </entry></row><row><entry>   <scenario_identifier>ID_scenario_1</scenario_identifier> </entry></row><row><entry>   <metric_identifier>ID_METRIC_EXPECTED_RETURN</metric_identifier> </entry></row><row><entry>   <metric_value>384</metric_value> </entry></row><row><entry>  </record> </entry></row><row><entry>  <record> </entry></row><row><entry>   <asset_id>AAPL</asset_id> </entry></row><row><entry>   <pricing_date>2020-04-17</pricing_date> </entry></row><row><entry>   <simulation_identifier>ID_sim_1</simulation_identifier> </entry></row><row><entry>   <scenario_identifier>ID_scenario_2</scenario_identifier> </entry></row><row><entry>   <metric_identifier>ID_METRIC_EXPECTED_RETURN</metric_identifier> </entry></row><row><entry>   <metric_value>430</metric_value> </entry></row><row><entry>  </record> </entry></row><row><entry>  ... </entry></row><row><entry>  <record> </entry></row><row><entry>   <asset_id>AAPL</asset_id> </entry></row><row><entry>   <pricing_date>2020-04-17</pricing_date> </entry></row><row><entry>   <simulation_identifier>ID_sim_1</simulation_identifier> </entry></row><row><entry>   <scenario_identifier>ID_scenario_1</scenario_identifier> </entry></row><row><entry>   <metric_identifier>ID_METRIC_CVAR</metric_identifier> </entry></row><row><entry>   <metric_value>−10.05%</metric_value> </entry></row><row><entry>  </record> </entry></row><row><entry>  <record> </entry></row><row><entry>   <asset_id>AAPL</asset_id> </entry></row><row><entry>   <pricing_date>2020-04-17</pricing_date> </entry></row><row><entry>   <simulation_identifier>ID_sim_1</simulation_identifier> </entry></row><row><entry>   <scenario_identifier>ID_scenario_2</scenario_identifier> </entry></row><row><entry>   <metric_identifier>ID_METRIC_CVAR</metric_identifier> </entry></row><row><entry>   <metric_value>−7.15%</metric_value> </entry></row><row><entry>  </record> </entry></row><row><entry>  ... </entry></row><row><entry> </asset_measure_table_data> </entry></row><row><entry></asset_return_metrics_calculation_response> </entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0450The application server <b>3406</b> may send a portfolio returns visualization response <b>3441</b> to the client <b>3402</b> to provide a visualization of portfolio return metrics for the specified portfolio. In one implementation, the portfolio returns visualization response may include data such as a response identifier, visualization data, and/or the like. In one embodiment, the application server may provide the following example portfolio returns visualization response, substantially in the form of a HTTP(S) POST message including XML-formatted data, as provided below:

0000<tables id="TABLE-US-00071" num="00071"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>POST /portfolio_returns_visualization_response.php HTTP/1.1 </entry></row><row><entry>Host: www.server.com </entry></row><row><entry>Content-Type: Application/XML </entry></row><row><entry>Content-Length: 667 </entry></row><row><entry> </entry></row><row><entry><portfolio_returns_visualization_response> </entry></row><row><entry> <response_identifier>ID_response_51</response_identifier> </entry></row><row><entry> <visualization_data> </entry></row><row><entry>  portfolio return metrics data (e.g., constituent securities' and/or </entry></row><row><entry>  portfolio′s returns, worst returns, return volatility, frequency vs. </entry></row><row><entry>  returns data)</entry></row><row><entry> </visualization_data> </entry></row><row><entry></portfolio_returns_visualization_response> </entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0451<figref idref="DRAWINGS">FIG. 35</figref> shows a logic flow illustrating embodiments of a portfolio returns visualizing (PRV) component for the MLPO. In <figref idref="DRAWINGS">FIG. 35</figref>, a portfolio returns visualization request may be obtained at <b>3501</b>. For example, the portfolio returns visualization request may be obtained as a result of a user requesting generation of a portfolio returns visualization.

0452Market scenarios to utilize for generating the portfolio returns visualization may be determined at <b>3505</b>. In one embodiment, the market scenarios to utilize may be determined based on the simulation model (e.g., for a specified pricing date) and/or time period length selected by the user. In another embodiment, the market scenarios to utilize may be determined based on filters applied to simulated market scenarios. In one implementation, the portfolio returns visualization request may be parsed (e.g., using PHP commands) to determine the market scenarios to utilize (e.g., based on the values of the simulation_model and/or pricing-date fields). For example, the selected simulation model and/or pricing date may be used to determine a simulation identifier (e.g., ID_sim_1) of the corresponding simulation (e.g., a set of simulated market scenarios).

0453Portfolio securities of a portfolio may be determined at <b>3509</b> and portfolio securities weights for the portfolio securities may be determined at <b>3513</b>. In one embodiment, the portfolio securities and/or the corresponding portfolio securities weights may be retrieved from a database (e.g., based on a portfolio identifier). In one implementation, the portfolio returns visualization request may be parsed (e.g., using PHP commands) to determine the portfolio identifier (e.g., based on the value of the portfolio_identifier field). In another embodiment, the portfolio securities and/or the corresponding portfolio securities weights may be specified by the user (e.g., via a set of securities universe widgets as discussed with regard to <figref idref="DRAWINGS">FIG. 10</figref>, via a set of security selection widgets as discussed with regard to <figref idref="DRAWINGS">FIG. 41</figref>). In one implementation, the portfolio returns visualization request may be parsed (e.g., using PHP commands) to determine the specified portfolio securities and/or the corresponding portfolio securities weights. In another embodiment, the portfolio securities and/or the corresponding portfolio securities weights may be determined based on an optimization. In one implementation, the portfolio securities and/or the corresponding portfolio securities weights may be determined as discussed with regard to the PC component. In another implementation, the portfolio securities and/or the corresponding portfolio securities weights may be determined as discussed with regard to <figref idref="DRAWINGS">FIG. 48</figref>.

0454Asset return metrics data for the portfolio securities may be obtained via the ARMC component at <b>3517</b>. In one embodiment, an application (e.g., executed by an application server) may be configured to generate a portfolio returns visualization comprising a set of visualization return metrics, and the asset return metrics data utilized to calculate the set of visualization return metrics may be obtained using the database calculation engine (e.g., via an asset return metrics calculation request). In one implementation, asset simulation wide table data (e.g., utilized for calculating expected portfolio return metrics for the portfolio) and/or asset measure table data (e.g., utilized for calculating expected security return metrics for the constituent securities of the portfolio) may be obtained. See <b>706</b> in <figref idref="DRAWINGS">FIG. 7C</figref> for an example of asset simulation wide table data. See <b>710</b> in <figref idref="DRAWINGS">FIG. 7C</figref> for an example of asset measure table data.

0455A determination may be made at <b>3521</b> whether there remain visualization return metrics to determine. In one implementation, each of the visualization return metrics in the set of visualization return metrics may be determined. If there remain visualization return metrics to determine, the next visualization return metric may be selected for processing at <b>3525</b>.

0456A determination may be made at <b>3529</b> regarding the type of the selected visualization return metric. In one embodiment, a visualization return metric may be an expected portfolio return metric calculated for a portfolio. In another embodiment, a visualization return metric may be an expected security return metric calculated for a security.

0457If the selected visualization return metric type is portfolio, the selected expected portfolio return metric for the portfolio may be determined using the asset simulation wide table data at <b>3533</b>. For example, expected portfolio return metrics for a portfolio may include the portfolio's expected return, worst returns, return volatility, frequency vs. returns data, and/or the like. In various implementations, the selected expected portfolio return metric for the portfolio may be calculated using a weighted average (e.g., weighted based on the portfolio securities weights) of expected security returns and/or of determined expected security return metrics for the constituent securities of the portfolio using the asset simulation wide table data. For example, the following API may be utilized to determine expected portfolio return metrics, in the set of visualization return metrics, for the portfolio for the market scenarios to utilize:

0458POST API/RUNANALYSIS <ul id="ul0045" list-style="none"><li id="ul0045-0001" num="0000"><ul id="ul0046" list-style="none"><li id="ul0046-0001" num="0459">This API facilitates generating portfolio return metrics visualization for a specified portfolio (e.g., list of securities). The portfolio return metrics calculation results are included in the Summary object returned by the API.</li><li id="ul0046-0002" num="0460">The API returns HTTP/1.1 status code 201 if the request is successful. It returns 500 Internal Server Error if there is an exception.</li></ul></li></ul>

0461Input Parameter Details

0000<tables id="TABLE-US-00072" num="00072"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="28pt" align="left" /><colspec colname="4" colwidth="91pt" align="left" /><thead><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>Attribute name</entry><entry>Mandatory</entry><entry>Default</entry><entry>Description/Rule</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>securityInputs</entry><entry>Y</entry><entry /><entry>Specify the initial</entry></row><row><entry /><entry /><entry /><entry>investment</entry></row><row><entry>simulationId</entry><entry>Y</entry><entry>0</entry><entry>Taxable = 1, Tax-Exempt = 0</entry></row><row><entry>simulationInputs</entry><entry>Y</entry><entry /><entry>List of factor min and max</entry></row><row><entry /><entry /><entry /><entry>range for filtering of</entry></row><row><entry /><entry /><entry /><entry>scenarios</entry></row><row><entry>businessCycleInputs</entry><entry>N</entry><entry /><entry>List of business cycle</entry></row><row><entry /><entry /><entry /><entry>inputs and associated</entry></row><row><entry /><entry /><entry /><entry>percentages. (e.g., Late</entry></row><row><entry /><entry /><entry /><entry>Cycle 50% and Recession</entry></row><row><entry /><entry /><entry /><entry>50%)</entry></row><row><entry>pricingDt</entry><entry>Y</entry><entry /><entry>Current Pricing Date for</entry></row><row><entry /><entry /><entry /><entry>which simulation data is</entry></row><row><entry /><entry /><entry /><entry>available</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00073" num="00073"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="266pt" align="center" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>REQUEST</entry></row><row><entry>POST API/runAnalysis </entry></row><row><entry>Content-type: application/json </entry></row><row><entry>{″securityInputs″:[{″cusip″:″806551E139″, ″qty″:9000,″price″:101.11}, </entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>{″cusip″:″806640VU9″, ″qty″:14000,″price″:100}], </entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="266pt" align="left" /><tbody valign="top"><row><entry>″simulationId″:6, </entry></row><row><entry>″scenarioInputs″:[{</entry></row><row><entry> ″id″:1, </entry></row><row><entry> ″type″:1, </entry></row><row><entry> ″simulationInputs″:[{″factorName″:″VIX″,″rangeStart″:−4588,″rangeEnd″:6796}, </entry></row><row><entry>  {″factorName″:″SP500″,″rangeStart″:−5161,″rangeEnd″:4082}], </entry></row><row><entry> ″businessCycleInputs″:[ ] </entry></row><row><entry>},{</entry></row><row><entry> ″id″:2, </entry></row><row><entry> ″type″:1, </entry></row><row><entry> ″simulationInputs″:[ ], </entry></row><row><entry> ″businessCycleInputs″:[{cycleName: ″Late″, percentage: 100}, {cycleName: </entry></row><row><entry>  ″Recession″, percentage: </entry></row><row><entry>0}]</entry></row><row><entry>},...], </entry></row><row><entry>“pricingDt”:”02/26/2020”, </entry></row><row><entry>″logger″:true </entry></row><row><entry>} </entry></row><row><entry>RESPONSE</entry></row><row><entry>201 </entry></row><row><entry>Content-Type: application/json </entry></row><row><entry>{</entry></row><row><entry> ″summary″: [{</entry></row><row><entry>  “id”:1, </entry></row><row><entry>  “risk”: 234.42, </entry></row><row><entry>  “mean”: 255, </entry></row><row><entry>  “cvar”: −202.09, </entry></row><row><entry>  “5per”: −172, </entry></row><row><entry>  “25per”: −74, </entry></row><row><entry>  “50per”: −24, </entry></row><row><entry>  “75per”: 154, </entry></row><row><entry>  “95per”: 34, </entry></row><row><entry> },{</entry></row><row><entry>  “Id”:2, </entry></row><row><entry>  “risk”: 258.30, </entry></row><row><entry>  “mean”: 267, </entry></row><row><entry>  “cvar”: −256.09, </entry></row><row><entry>  “5per”: −176, </entry></row><row><entry>  “25per”: −74, </entry></row><row><entry>  “50per”: −21, </entry></row><row><entry>  “75per”: 165, </entry></row><row><entry>  “95per”: 38, </entry></row><row><entry> },...], </entry></row><row><entry> “marketReturns”:[ {</entry></row><row><entry>  ″marketId”: 959, </entry></row><row><entry>  ″bucketId″: 4, </entry></row><row><entry>  ″marketReturn″: −434.16 </entry></row><row><entry>  }, {</entry></row><row><entry>  ″marketId″: 2527, </entry></row><row><entry>  ″bucketId″: 6, </entry></row><row><entry>  ″marketReturn″: −252.16 </entry></row><row><entry>  }, </entry></row><row><entry>  ... </entry></row><row><entry> ]</entry></row><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0462If the selected visualization return metric type is security, the selected expected security return metric for the portfolio securities of the portfolio may be determined using the asset measure table data at <b>3537</b>. For example, expected security return metrics for a security may include the security's expected return, worst returns, return volatility, frequency vs. returns data, and/or the like. In various implementations, the selected expected security return metric for each security may be determined (e.g., retrieved, calculated) using the asset measure table data. For example, the following API may be utilized to determine expected security return metrics, in the set of visualization return metrics, for the portfolio securities of the portfolio for the market scenarios to utilize:

0000<tables id="TABLE-US-00074" num="00074"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="91pt" align="left" /><colspec colname="4" colwidth="56pt" align="left" /><thead><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>Operation</entry><entry /><entry /><entry /></row><row><entry>on</entry><entry>Operation</entry><entry /><entry /></row><row><entry>Entities</entry><entry>Type</entry><entry>End Point</entry><entry>Description</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Run Bond</entry><entry>POST</entry><entry>api/runBondLadderOptimizer</entry><entry>Gets the bond</entry></row><row><entry>Ladder</entry><entry /><entry /><entry>ladder based on</entry></row><row><entry>Optimizer</entry><entry /><entry /><entry>rule-based</entry></row><row><entry /><entry /><entry /><entry>optimization. The</entry></row><row><entry /><entry /><entry /><entry>API automatically</entry></row><row><entry /><entry /><entry /><entry>calls the</entry></row><row><entry /><entry /><entry /><entry>available bonds</entry></row><row><entry /><entry /><entry /><entry>API to get</entry></row><row><entry /><entry /><entry /><entry>available bonds</entry></row><row><entry /><entry /><entry /><entry>based on filter</entry></row><row><entry /><entry /><entry /><entry>criteria. It then</entry></row><row><entry /><entry /><entry /><entry>constructs the</entry></row><row><entry /><entry /><entry /><entry>bond ladder.</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0463POST API/RUNBONDLADDEROPTIMIZER <ul id="ul0047" list-style="none"><li id="ul0047-0001" num="0000"><ul id="ul0048" list-style="none"><li id="ul0048-0001" num="0464">This API facilitates generating portfolio returns visualization. This API returns the bond ladder based on filter specified as part of the input. The API automatically calls the available bonds, applies the filter and then returns bond ladder based on rule-based optimization.</li><li id="ul0048-0002" num="0465">The API returns HTTP/1.1 status code 201 if the request is successful. It returns 500 Internal Server Error if there is an exception.</li></ul></li></ul>

0466Input Parameter Details

0000<tables id="TABLE-US-00075" num="00075"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="35pt" align="left" /><colspec colname="4" colwidth="91pt" align="left" /><thead><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>Attribute name</entry><entry>Mandatory</entry><entry>Default</entry><entry>Description/Rule</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>startInvestment</entry><entry>Y</entry><entry>0</entry><entry>Specify the initial</entry></row><row><entry /><entry /><entry /><entry>investment</entry></row><row><entry>startYear</entry><entry>Y</entry><entry /><entry>Integer between 1 and 50</entry></row><row><entry>endYear</entry><entry>Y</entry><entry /><entry>Integer between 1 and 50.</entry></row><row><entry /><entry /><entry /><entry>Should be greater than</entry></row><row><entry /><entry /><entry /><entry>startYear</entry></row><row><entry>taxStatus</entry><entry>N</entry><entry>1</entry><entry>Taxable = 1, Tax-Exempt = 0</entry></row><row><entry>composition</entry><entry>N</entry><entry /><entry /></row><row><entry>filter</entry><entry>Y</entry><entry>FALSE</entry><entry>Set to TRUE if filter</entry></row><row><entry /><entry /><entry /><entry>should be applied.</entry></row><row><entry>creditquality</entry><entry>N</entry><entry /><entry>Mandatory if Filter is set</entry></row><row><entry /><entry /><entry /><entry>to TRUE</entry></row><row><entry>federalTax</entry><entry>N</entry><entry /><entry /></row><row><entry>stateTax</entry><entry>N</entry><entry /><entry /></row><row><entry>surTax</entry><entry>N</entry><entry /><entry /></row><row><entry>step</entry><entry>Y</entry><entry>1</entry><entry>Integer value to specify</entry></row><row><entry /><entry /><entry /><entry>the Yield Range:</entry></row><row><entry /><entry /><entry /><entry>1 = Full Market (1st to 4th</entry></row><row><entry /><entry /><entry /><entry>Quartiles)</entry></row><row><entry /><entry /><entry /><entry>2 = Standard (2nd and 3rd</entry></row><row><entry /><entry /><entry /><entry>Quartile)</entry></row><row><entry /><entry /><entry /><entry>3 = Conservative (1st and</entry></row><row><entry /><entry /><entry /><entry>2nd Quartile)</entry></row><row><entry /><entry /><entry /><entry>4 = Aggressive (3rd and 4th</entry></row><row><entry /><entry /><entry /><entry>Quartile)</entry></row><row><entry>diversification</entry><entry>Y</entry><entry>0.03</entry><entry>Integer value to specify</entry></row><row><entry /><entry /><entry /><entry>the Diversification (i.e.,</entry></row><row><entry /><entry /><entry /><entry>max allowed allocation</entry></row><row><entry /><entry /><entry /><entry>based on the percentage of</entry></row><row><entry /><entry /><entry /><entry>total market value of the</entry></row><row><entry /><entry /><entry /><entry>portfolio):</entry></row><row><entry /><entry /><entry /><entry>0.03 = High (Max Position</entry></row><row><entry /><entry /><entry /><entry>size = 3%)</entry></row><row><entry /><entry /><entry /><entry>0.05 = Medium (Max Position</entry></row><row><entry /><entry /><entry /><entry>size = 5%)</entry></row><row><entry /><entry /><entry /><entry>0.07 = Low (Max Position</entry></row><row><entry /><entry /><entry /><entry>size = 7%)</entry></row><row><entry /><entry /><entry /><entry>1 = No Limit on Position</entry></row><row><entry /><entry /><entry /><entry>size</entry></row><row><entry>riskAdjusted</entry><entry>N</entry><entry>FALSE</entry><entry>FALSE = Maximize Yield</entry></row><row><entry /><entry /><entry /><entry>TRUE = Risk Adjusted Yield</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00076" num="00076"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>REQUEST</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>POST API/runBondLadderOptimizer </entry></row><row><entry /><entry>Content-type: application/json </entry></row><row><entry /><entry>{</entry></row><row><entry /><entry> ″startInvestment″: 1000000, </entry></row><row><entry /><entry> ″startYear″: 1, </entry></row><row><entry /><entry> ″endYear″: 15, </entry></row><row><entry /><entry> ″taxStatus″: 1, </entry></row><row><entry /><entry> ″composition″: 1, </entry></row><row><entry /><entry> ″filter″: true, </entry></row><row><entry /><entry> ″creditquality″: ″BB+″, </entry></row><row><entry /><entry> ″federalTax″: 37, </entry></row><row><entry /><entry> ″stateTax″: 5.1, </entry></row><row><entry /><entry> ″surTax″: 3.8, </entry></row><row><entry /><entry> ″step″: 4, </entry></row><row><entry /><entry> ″diversification″: 0.03, </entry></row><row><entry /><entry> “riskAdjusted”:true </entry></row><row><entry /><entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry>RESPONSE</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>201 </entry></row><row><entry /><entry>Content-Type: application/json </entry></row><row><entry /><entry>{</entry></row><row><entry /><entry> ″yield″: 4.515983619734928, </entry></row><row><entry /><entry> “proposed”:[ {</entry></row><row><entry /><entry>  ″fmrCusip″: ″AEG778000″, </entry></row><row><entry /><entry>  ″description″: ″ALPHABET INC 3.625% 05/19/21″, </entry></row><row><entry /><entry>  ″price″: 103.04, </entry></row><row><entry /><entry>  ″yearsToMaturity″: 2, </entry></row><row><entry /><entry>  ″staticYield″: 1.774, </entry></row><row><entry /><entry>  ″minDenomination″: 2000, </entry></row><row><entry /><entry>  ″minIncrement″: 1000, </entry></row><row><entry /><entry>  ″rating″: ″AA″, </entry></row><row><entry /><entry>  ″ratingGrp″: 0, </entry></row><row><entry /><entry>  ″tradableQty″: 40, </entry></row><row><entry /><entry>  ″kdp_1yr″: 0.011852, </entry></row><row><entry /><entry>  ″kdp_2yr″: 0.076579, </entry></row><row><entry /><entry>  ″kdp_3yr″: 0.117952, </entry></row><row><entry /><entry>  ″kdp_4yr″: 0.134964, </entry></row><row><entry /><entry>  ″kdp_5yr″: 0.177211, </entry></row><row><entry /><entry>  ″kdp_7yr″: 0.267062, </entry></row><row><entry /><entry>  ″kdp_10yr″: 0.267116, </entry></row><row><entry /><entry>  ″ratingsIndex″: 2, </entry></row><row><entry /><entry>  ... </entry></row><row><entry /><entry> }...], </entry></row><row><entry /><entry> “bondLadderList”:[ {</entry></row><row><entry /><entry>  ″marketValue″: 67000, </entry></row><row><entry /><entry>  ″priceChange″: 45159.83619734928, </entry></row><row><entry /><entry>  ″defaultValue″: 0, </entry></row><row><entry /><entry>  ″yearsToMaturity″: 11, </entry></row><row><entry /><entry>  ″securities″: [ ]}...], </entry></row><row><entry /><entry> “ratingsList”:[ {</entry></row><row><entry /><entry>  ″rating″: ″AA″, </entry></row><row><entry /><entry>  ″weight″: 0.0028821924148899635 </entry></row><row><entry /><entry> }...], </entry></row><row><entry /><entry> “logs”:[...] </entry></row><row><entry /><entry>}</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0467A visualization of the expected portfolio return metrics for the portfolio and/or of the expected security return metrics for the constituent securities of the portfolio for the market scenarios to utilize may be generated at <b>3541</b>. In one implementation, user interface widgets showing the expected portfolio return metrics and/or the expected security return metrics may be generated via a portfolio returns visualization response. See <figref idref="DRAWINGS">FIGS. 22-25, 28-30, and 41-47</figref> for examples of visualizations that may be generated.

0468<figref idref="DRAWINGS">FIG. 36</figref> shows a logic flow illustrating embodiments of an asset return metrics calculating (ARMC) component for the MLPO. In <figref idref="DRAWINGS">FIG. 36</figref>, an asset return metrics calculation request may be obtained at <b>3601</b>. For example, the asset return metrics calculation request may be obtained as a result of an application requesting calculation of asset return metrics data.

0469Assets to analyze may be determined at <b>3605</b>. In one embodiment, asset return metrics data may be calculated for the determined assets. In one implementation, the asset return metrics calculation request may be parsed (e.g., using PHP commands) to determine the assets (e.g., a set of portfolio securities) to analyze (e.g., based on the value of the securities field). In another implementation, the assets (e.g., a universe of securities (e.g., bonds)) to analyze may be determined (e.g., to precalculate and/or cache asset return metrics data) based on a configuration setting.

0470A simulation identifier to utilize may be determined at <b>3609</b>. In one embodiment, the simulation identifier may identify a set of simulated market scenarios to utilize to calculate asset return metrics data. See <figref idref="DRAWINGS">FIGS. 2A-B</figref> and <figref idref="DRAWINGS">FIG. 4</figref> for additional details regarding the MLSSP component, which may be used to generate simulated market scenarios. In one implementation, the asset return metrics calculation request may be parsed (e.g., using PHP commands) to determine the simulation identifier (e.g., based on the value of the simulation_identifier field).

0471A pricing date to utilize may be determined at <b>3613</b>. In one embodiment, the pricing date may represent the date for which analytics (e.g., Key Rate Durations (KRD), Option Adjusted Spread, Muni KRDs, etc.) for the assets are available and/or when asset simulations are calculated. In one implementation, the asset return metrics calculation request may be parsed (e.g., using PHP commands) to determine the pricing date (e.g., based on the value of the pricing_date field). In another implementation, the latest available pricing date may be utilized.

0472Assets may be filtered based on available factor exposures at <b>3617</b>. In one embodiment, such filtering is a data reduction technique utilized to reduce the number of records used during calculations thus lowering processing time. In one implementation, the factor exposure table (e.g., factor_expo table in <figref idref="DRAWINGS">FIG. 40</figref>) may comprise data calculated for assets that have analytics available, while the assets table (e.g., asset table in <figref idref="DRAWINGS">FIG. 40</figref>) may comprise data for the available assets (e.g., assets in the universe of securities, assets in the set of portfolio securities). This filtering ensures that those assets for which factor exposures are available are processed. In various implementations, assets may be processed using sessions (e.g., as discussed with regard to <b>3633</b>) with each session targeting specific range of assets to be processed. For example, if the assets are processed in 4 sessions, the first session may target the first 250K assets, the second session may target assets from 250K to 500K, and so on. Each session may be configured to have access to its own set of global temporary tables that is used to store information related to the assets the respective session is processing (e.g., data may not be shared between sessions). Reducing the assets to those assets that are processed by a session and storing in a global temporary table for the session ensures that big table joins are eliminated during the asset return calculation process. In some implementations, the asset return calculation process may be rerunnable, and may be configured to ignores the assets that are already processed in the previous run. For example, the assets may be filtered based on available factor exposures via an Oracle RDS on Cloud database command similar to the following: <ul id="ul0049" list-style="none"><li id="ul0049-0001" num="0000"><ul id="ul0050" list-style="none"><li id="ul0050-0001" num="0473">In the query below, the factor exposure is reduced to the assets being targeted in the session and further reduced to ignore assets that are already processed if the asset return calculation process is rerun.</li></ul></li></ul>

0000<tables id="TABLE-US-00077" num="00077"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>INSERT INTO <db-schema>.global_asset_list </entry></row><row><entry>SELECT DISTINCT fe.asset_id </entry></row><row><entry>FROM </entry></row><row><entry> (SELECT DISTINCT asset_id FROM <db-schema>.factor_expo </entry></row><row><entry> WHERE pricing_dt = lc_truncatedPricingDate </entry></row><row><entry> ORDER BY asset_id offset p_offset ROWS </entry></row><row><entry> FETCH NEXT p_rangeVal ROWS ONLY) fe </entry></row><row><entry>LEFT OUTER JOIN </entry></row><row><entry> (SELECT DISTINCT asset_id FROM <db-schema>.asset_sim_wide am </entry></row><row><entry> WHERE am.pricing_dt = lc_truncatedPricingDate) asw </entry></row><row><entry>ON (fe.asset_id = asw.asset_id) </entry></row><row><entry>WHERE asw.asset_id IS NULL;</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0474Factor simulations may be filtered based on the filtered assets at <b>3621</b>. In one embodiment, such filtering is a data reduction technique utilized to reduce the number of records used during calculations thus lowering processing time. In one implementation, the factor simulations table (e.g., factor_sim table in <figref idref="DRAWINGS">FIG. 40</figref>) may comprise simulated returns for market factors (e.g., 40+ factors which is around 300K records). This filtering determines a set of market factors to which the filtered assets have exposure (e.g., this reduces the number of factor simulation records that are loaded by 50%, to around 150K records, and/or reduces the JOIN for further processing). In some implementations, a factor simulation may contain factor simulation data for multiple simulations with multiple simulation dates. Filtering the table to include targeted simulation ids reduces the number of records that are utilized for calculations. Each asset may have exposure to certain factors and using the factors that the targeted assets have exposure to can further reduce the size of the factor simulation table that is processed. For example, for 250K assets, the unique factors that these assets have access to may be 10 instead of 40+ factors for which factor simulations are available. Reducing the factor simulation to include factor simulations for fewer factors reduce the number of records. Also, storing the data in temporary table instead of using the main table reduces the need to filter data during calculations. For example, the factor simulations may be filtered based on the filtered assets via an Oracle RDS on Cloud database command similar to the following:

0000<tables id="TABLE-US-00078" num="00078"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="266pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>INSERT INTO <db-schema>.mglobal_factor_sim_tmp </entry></row><row><entry>SELECT * </entry></row><row><entry>FROM <db-schema>.factor_sim fs </entry></row><row><entry>WHERE fs.sim_id IN (p_simIdQuarterly, p_simIdBiAnnually, p_simIdYearly) </entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><tbody valign="top"><row><entry>AND fs.factor_id IN ( </entry><entry>SELECT DISTINCT factor_id FROM <db-schema>.factor_expo fe </entry></row><row><entry /><entry>INNER JOIN <db-schema>.global_asset_list gal </entry></row><row><entry /><entry>ON fe.asset_id = gal.asset_id </entry></row><row><entry /><entry>WHERE fe.pricing_dt = lc_truncatedPricingDate )</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0475In some implementations, the factor exposure table and the factor simulations table may be augmented to integrate the impact of convexity in asset simulation. The convexity metric (e.g., option adjusted convexity) may be obtained from Sentinel's security_master table. The factor exposure table may be augmented by inserting convexity as (e.g., two) new market factors (e.g., id 80 for non-muni instruments, id 81 for muni instruments). For example, the exposure table may be augmented via an Oracle RDS on Cloud database command similar to the following:

0000<tables id="TABLE-US-00079" num="00079"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>SELECT cusip as asset_id, 80 as factor_id, 1/2 * </entry></row><row><entry /><entry> security_master.option_adjusted_convexity / 10000 as exposure </entry></row><row><entry /><entry>FROM security_master </entry></row><row><entry /><entry>WHERE product_name != ′Municipal′</entry></row><row><entry /><entry>UNION ALL </entry></row><row><entry /><entry>SELECT cusip as asset_id, 81 as factor_id, 1/2 * </entry></row><row><entry /><entry> security_master.option_adjusted_convexity / 10000 as exposure </entry></row><row><entry /><entry>FROM security_master </entry></row><row><entry /><entry>WHERE product_name = ′Municipal′</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0476The factor simulations table may be augmented by inserting the square of the change in yield (e.g., using the average return of different key rates as the proxy for the change in yield) as (e.g., two) new market factors (e.g., id 80 for Treasury curves, id 81 for muni curves) for each simulation and each market scenario. For example, the factor simulations table may be augmented via an Oracle RDS on Cloud database command similar to the following:

0000<tables id="TABLE-US-00080" num="00080"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>/* </entry></row><row><entry> Treasury curves 3M, 6M, 1Y, 2Y, 3Y, 5Y, 7Y, 10Y, 20Y, 30Y </entry></row><row><entry> Muni curves 2Y, 5Y, 10Y, 20Y </entry></row><row><entry>*/ </entry></row><row><entry>with oac_factor as </entry></row><row><entry>( </entry></row><row><entry> select fs.sim_id, fs.market_id, power(avg(fs.return), 2) as return, </entry></row><row><entry> case when f.type = ′Treasury Curves′ then 80 </entry></row><row><entry>  when f.type = ′Muni Curves′ then 81 </entry></row><row><entry> end as factor_id </entry></row><row><entry> from factor_sim fs, factor f </entry></row><row><entry> where fs.factor_id = f.id </entry></row><row><entry> and fs.factor_id in </entry></row><row><entry>  (select f.id from factor f where f.type = ′Treasury Curves′ or f.type = </entry></row><row><entry>   ′Muni Curves′) </entry></row><row><entry> group by fs.sim_id, f.type, fs.market_id </entry></row><row><entry> order by fs.market_id </entry></row><row><entry>) </entry></row><row><entry>select distinct fs.sim_id, fs.market_id, fs.bucket_id, oo.factor_id, oo.return </entry></row><row><entry>from oac_factor oo, factor_sim fs </entry></row><row><entry>where oo.sim_id=fs.sim_id </entry></row><row><entry>and oo.market_id=fs.market_id </entry></row><row><entry>order by sim_id, market_id</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0477Factor exposures may be filtered based on the filtered assets and/or the pricing date at <b>3625</b>. In one embodiment, such filtering is a data reduction technique utilized to reduce the number of records used during calculations thus lowering processing time. In one implementation, the factor exposure table may store factor exposures for assets for multiple pricing dates (e.g., for the last three runs/dates). This filtering determines a set of factor exposure records for the pricing date (e.g., for the current pricing date and filters out records for older pricing dates) that are associated with the filtered assets (e.g., assets for which factor exposures are available). For example, the factor exposures may be filtered based on the filtered assets and/or the pricing date via an Oracle RDS on Cloud database command similar to the following:

0000<tables id="TABLE-US-00081" num="00081"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>INSERT INTO <db-schema>.mglobal_factor_expo_tmp </entry></row><row><entry /><entry> SELECT fe.* </entry></row><row><entry /><entry> FROM <db-schema>.factor_expo fe </entry></row><row><entry /><entry> INNER JOIN <db-schema>.global_asset_list gal </entry></row><row><entry /><entry>  ON fe.asset_id = gal.asset_id </entry></row><row><entry /><entry> WHERE fe.pricing_dt = lc_truncatedPricingDate;</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0478Call and/or put schedules may be filtered based on the filtered assets at <b>3629</b>. In one embodiment, such filtering is a data reduction technique utilized to reduce the number of records used during calculations thus lowering processing time. In one implementation, the call schedule table (e.g., call_schedule table in <figref idref="DRAWINGS">FIG. 40</figref>) and/or the put schedule table (e.g., put_schedule table in <figref idref="DRAWINGS">FIG. 40</figref>) may comprise call and/or put prices for the available assets (e.g., assets in the universe of securities, assets in the set of portfolio securities). This filtering determines a set of call and/or put schedule records that are associated with the filtered assets (e.g., assets for which factor exposures are available). For example, the call and/or put schedules may be filtered based on the filtered assets via an Oracle RDS on Cloud database command similar to the following: <ul id="ul0051" list-style="none"><li id="ul0051-0001" num="0000"><ul id="ul0052" list-style="none"><li id="ul0052-0001" num="0479">The query below is separated out into two parts. The first part focuses on getting the call and put price based on different horizons and call date. The second part focuses on calculating the call and put returns which will result in defining the lower cap of the simulated returns.</li></ul></li></ul>

0000<tables id="TABLE-US-00082" num="00082"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="266pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>INSERT /*+ APPEND PARALLEL(8) */ </entry></row><row><entry>INTO <db-schema>.mglobal_call_schedule_tmp </entry></row><row><entry>    SELECT </entry></row><row><entry>     nvl(call_price_1y.cusp_n,put_price_1y.cusp_n) AS cusp_n, </entry></row><row><entry>     call_price_1y.red_price_a c_prc_1y, </entry></row><row><entry>     put_price_1y.red_price_a p_prc_1y, </entry></row><row><entry>     least(nvl(call_price_1y.red_eff_d,′31-DEC- </entry></row><row><entry>2099′),nvl(put_price_1y.red_eff_d,′31-DEC-2099′) ) red_eff_d </entry></row><row><entry>    FROM </entry></row><row><entry>     ( </entry></row><row><entry>      SELECT cusp_n, red_eff_d, red_price_a </entry></row><row><entry>      FROM </entry></row><row><entry>       ( </entry></row><row><entry>        SELECT cusp_n, red_eff_d, red_price_a, ROW_NUMBER( ) </entry></row><row><entry>OVER( </entry></row><row><entry>          PARTITION BY cusp_n </entry></row><row><entry>          ORDER BY </entry></row><row><entry>           red_eff_d </entry></row><row><entry>         ) rownumber </entry></row><row><entry>        FROM </entry></row><row><entry>         ( </entry></row><row><entry>          SELECT cusp_n, red_eff_d, red_price_a </entry></row><row><entry>          FROM </entry></row><row><entry>           <db-schema>.call_schedule </entry></row><row><entry>          WHERE </entry></row><row><entry>           red_eff_d > lc_truncatedPricingDate </entry></row><row><entry>           AND ( ( red_eff_d − </entry></row><row><entry>lc_truncatedPricingDate ) / 365 < 1 ) </entry></row><row><entry>         ) </entry></row><row><entry>       ) </entry></row><row><entry>      WHERE </entry></row><row><entry>       rownumber = 1 </entry></row><row><entry>     ) call_price_1y </entry></row><row><entry>     FULL OUTER JOIN ( </entry></row><row><entry>      <query put_schedule table> </entry></row><row><entry>     ) put_price_1y ON call_price_1y.cusp_n = put_price_1y.cusp_n; </entry></row><row><entry>INSERT /*+ APPEND PARALLEL(8) */ </entry></row><row><entry> INTO <db-schema>.global_call_put_prices </entry></row><row><entry> SELECT </entry></row><row><entry>  /*+ full(asim) full(sm) full(cs) parallel(asim 8) parallel(sm 8) parallel(cs 8) */ </entry></row><row><entry>  b.asset_id asset_id, </entry></row><row><entry>  b.put_price_factor_1y, </entry></row><row><entry>  b.call_price_factor_1y, </entry></row><row><entry>  b.yield_to_worst_rate_factor * LEAST(lv_horizonQuarterly, b.maturity_factor) </entry></row><row><entry>quarterly_horizon_factor, </entry></row><row><entry>  b.yield_to_worst_rate_factor * LEAST(lv_horizonBiAnnually, b.maturity_factor) </entry></row><row><entry>biannual_horizon_factor, </entry></row><row><entry>  b.yield_to_worst_rate_factor * LEAST(lv_horizonYearly, b.maturity_factor) </entry></row><row><entry>yearly_horizon_factor </entry></row><row><entry> FROM </entry></row><row><entry>  (SELECT sm.cusp_n asset_id, </entry></row><row><entry>   NVL( (cs.p_prc_1y   / sm.cls_prc − 1) * </entry></row><row><entry>lv_callPricePutPriceMultiplicationFactor,−lv_putCallMaxValue) put_price_factor_1y, </entry></row><row><entry>   NVL( (cs.c_prc_1y   / sm.cls_prc − 1) * </entry></row><row><entry>lv_callPricePutPriceMultiplicationFactor, lv_putCallMaxValue) call_price_factor_1y, </entry></row><row><entry>   LEAST( ( (sm.mty_d   − lc_truncatedPricingDate ) / 365), NVL( ( (cs.red_eff_d </entry></row><row><entry>−lc_truncatedPricingDate)/ 365), lv_putCallMaxValue) ) maturity_factor, </entry></row><row><entry>   sm.calc_yld_to_wrst_rte * 100 yield_to_worst_rate_factor </entry></row><row><entry>  FROM <db-schema>.mglobal_security_master_tmp sm </entry></row><row><entry>  LEFT JOIN <db-schema>.mglobal_call_schedule_tmp cs </entry></row><row><entry>  ON sm.cusp_n = cs.cusp_n) b;</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0480The number of sessions to utilize for calculating asset return metrics data may be determined at <b>3633</b>. In one embodiment, asset return metrics data may be calculated using parallel queries with a specified degree of parallelism. Accordingly, each parallel query may be processed using a number of query server processes corresponding to the specified degree of parallelism. In various implementations, the degree of parallelism for a parallel query may be specified at the statement level, at the session level, at the table level, at the index level, and/or the like. For example, a parallel query may specify that 8 query server processes should be used for processing the parallel query. In one implementation, the number of sessions to utilize may be determined based on available server resources to maintain a consistent degree of parallelism by creating a balance between sessions and parallel query server processes (e.g., threads). For example, for a server having 32 processors (e.g., CPUs, physical cores, virtual cores), 4 sessions may be utilized (e.g., determined by dividing the number of available processors by the specified degree of parallelism). Each session may be utilized for calculating asset return metrics data as discussed with regard to <b>3637</b>-<b>3693</b>.

0481An assets range for a session may be determined at <b>3637</b>. In one embodiment, an assets range for a session may refer to the set of assets to be processed by the session. In one implementation, the assets range for the session may be determined by dividing the filtered assets based on the number of sessions. For example, if there are in total 800K filtered assets for which asset return metrics data should be calculated, the filtered assets may be divided into 4 sets of assets each targeting 200K unique assets, and the session may be assigned 1 of the 4 sets of assets as the session's session assets.

0482A determination may be made at <b>3641</b> whether there remain session assets to analyze. In one implementation, each of the session's session assets may be analyzed. If there remain session assets to analyze, a batch size to utilize may be determined at <b>3645</b>. In one implementation, the batch size may be specified in a configuration setting. For example, the batch size may be configured to be 1000 assets. In another implementation, the batch size may depend on the number of assets that remain to be analyzed. For example, if 300 assets remain to be analyzed, then the batch size may be 300 assets instead of 1000 assets.

0483A temporary table of session assets of the determined batch size may be created at <b>3649</b>. In one implementation, a session assets batch of the determined batch size may be selected from the session assets that remain to be analyzed. For example, the temporary table comprising the session assets batch may be created via an Oracle RDS on Cloud database command similar to the following:

0000<tables id="TABLE-US-00083" num="00083"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>INSERT INTO <db-schema>.global_asset_id_distinct_tmp </entry></row><row><entry /><entry> SELECT asset_id </entry></row><row><entry /><entry> FROM <db-schema>.global_asset_list </entry></row><row><entry /><entry> ORDER BY asset_id ASC offset lv_startIndex ROWS </entry></row><row><entry /><entry> FETCH NEXT lv_loopIncrement ROWS ONLY;</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0484A temporary table of factor simulations for the session assets batch may be created at <b>3653</b>. In one implementation, the temporary table of factor simulations may be created by transposing factor simulations to store factor simulations for simulation ids representing different time horizons (e.g., this may reduce the number of records in the join as data related to different simulations are available in columns, making the expected returns calculation as discussed with regard to <b>3661</b> three times faster). For example, the temporary table of factor simulations for the session assets batch may be created via an Oracle RDS on Cloud database command similar to the following:

0000<tables id="TABLE-US-00084" num="00084"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>INSERT INTO pfmofrdbo.global_factor_sim_tmp </entry></row><row><entry> SELECT * </entry></row><row><entry> FROM </entry></row><row><entry>  (SELECT fs2.market_id, </entry></row><row><entry>   fs2.factor_id, </entry></row><row><entry>   fs2.sim_id AS sim_id, </entry></row><row><entry>   fs2.return AS RETURN </entry></row><row><entry>  FROM </entry></row><row><entry>   (SELECT fs.* FROM <db-schema>.mglobal_factor_sim_tmp fs </entry></row><row><entry>   WHERE fs.factor_id IN </entry></row><row><entry>    (SELECT DISTINCT factor_id FROM <db-schema>.global_factor_expo_tmp) </entry></row><row><entry>   ) fs2 </entry></row><row><entry>  WHERE fs2.sim_id IN (p_simIdQuarterly, p_simIdBiAnnually, p_simIdYearly) </entry></row><row><entry>  ) PIVOT (SUM(RETURN) FOR (sim_id) IN (20 AS return_quarterly, 21 AS </entry></row><row><entry>return_biannual, 22 return_yearly));</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0485A temporary table of factor exposures for the session assets batch may be created at <b>3657</b>. In one implementation, the temporary table of factor exposures may be created by selecting filtered factor exposures for the session assets batch. For example, the temporary table of factor exposures for the session assets batch may be created via an Oracle RDS on Cloud database command similar to the following:

0000<tables id="TABLE-US-00085" num="00085"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry> </entry><entry>INSERT INTO <db-schema>.global_factor_expo_tmp </entry></row><row><entry /><entry /><entry> SELECT fe.* </entry></row><row><entry /><entry /><entry> FROM <db-schema>.mglobal_factor_expo_tmp fe </entry></row><row><entry /><entry /><entry> JOIN <db-schema>.global_asset_id_distinct_tmp age </entry></row><row><entry /><entry /><entry> ON fe.asset_id = age.asset_id </entry></row><row><entry /><entry /><entry> WHERE fe.pricing_dt = lc_truncatedPricingDate;</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0486Expected returns for the session assets batch may be calculated via parallel execution (e.g., via a parallel query) at <b>3661</b>. In one implementation, the expected returns for the session assets batch may be calculated as the sum product of the factor exposures for the session assets batch and the simulated returns of filtered factor simulations for the session assets batch. For example, the expected returns for the session assets batch may be calculated via parallel execution via an Oracle RDS on Cloud database command similar to the following:

0000<tables id="TABLE-US-00086" num="00086"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>SELECT</entry></row><row><entry /><entry> /*+ full(f) full(e) parallel(f 8) parallel(e 8) */ </entry></row><row><entry /><entry> e.asset_id asset_id, </entry></row><row><entry /><entry> f.market_id, </entry></row><row><entry /><entry> SUM(e.exposure * f.return_quarterly) return_quarterly, </entry></row><row><entry /><entry> SUM(e.exposure * f.return_biannual) return_biannual, </entry></row><row><entry /><entry> SUM(e.exposure * f.return_yearly) return_yearly </entry></row><row><entry /><entry>FROM <db-schema>.global_factor_sim_tmp f </entry></row><row><entry /><entry>JOIN <db-schema>.global_factor_expo_tmp e </entry></row><row><entry /><entry>ON (f.factor_id = e.factor_id) </entry></row><row><entry /><entry>GROUP BY e.asset_id, </entry></row><row><entry /><entry> f.market_id</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0487The expected returns for the session assets batch may be adjusted based on call and/or put schedules via parallel execution (e.g., via a parallel query) at <b>3665</b>. In one implementation, if an asset has an embedded call option redeemable within the investment horizon, the return from exercising the call option may be set as the upper bound of the simulated asset return, and/or if an asset has an embedded put option redeemable within the investment horizon, the return from exercising the put option may be set as the lower bound of the simulated asset return. For example, the call/put option schedules (e.g., including redemption dates and prices) may be obtained from Sentinel's call_schedule/put_schedule tables via an Oracle RDS on Cloud database command similar to the following:

0000<tables id="TABLE-US-00087" num="00087"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>SELECT as1.pricing_dt, as1.sim_id, as1.asset_id, as1.market_id,</entry></row><row><entry>greatest(least(as1.simulated_return, (cs.next_call_price/</entry></row><row><entry>sm.current_instrument_price − 1) * 10000), (ps.next_put_price/</entry></row><row><entry>sm.current_instrument_price − 1) * 10000)</entry></row><row><entry>FROM asset_sim as1, security_master sm, call_schedule cs, put_schedule ps </entry></row><row><entry>WHERE as1.asset_id = sm.cusip </entry></row><row><entry>AND as1.asset_id = cs.cusip </entry></row><row><entry>AND as1.asset_id = ps.cusip </entry></row><row><entry>AND cs.earliest_next_call_date &lt;= as1.investment_horizon </entry></row><row><entry>AND ps.earliest_next_put_date &lt;= as1.investment_horizon</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> For example, the expected returns for the session assets batch may be adjusted based on call and/or put schedules via parallel execution via an Oracle RDS on Cloud database command similar to the following:

0000<tables id="TABLE-US-00088" num="00088"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>SELECT</entry></row><row><entry>  /*+ full(asim) full(scp) parallel(asim 8) parallel(scp 8) */ </entry></row><row><entry>  asim.asset_id, </entry></row><row><entry>  asim.market_id, </entry></row><row><entry>  GREATEST(GREATEST(scp.put_price_factor_3m, LEAST(asim.return_quarterly, </entry></row><row><entry>scp.call_price_factor_3m ) ) + scp.quarterly_horizon_factor, −10000) return_quarterly, </entry></row><row><entry>  GREATEST(GREATEST(scp.put_price_factor_6m, LEAST(asim.return_biannual, </entry></row><row><entry>scp.call_price_factor_6m ) ) + scp.biannual_horizon_factor, −10000) return_biannual, </entry></row><row><entry>  GREATEST(GREATEST(scp.put_price_factor_1y, LEAST(asim.return_yearly, </entry></row><row><entry>scp.call_price_factor_1y ) ) + scp.yearly_horizon_factor, −10000) return_yearly </entry></row><row><entry> FROM </entry></row><row><entry>  (SELECT </entry></row><row><entry>   /*+ full(f) full(e) parallel(f 8) parallel(e 8) */ </entry></row><row><entry>   e.asset_id asset_id, </entry></row><row><entry>   f.market_id, </entry></row><row><entry>   . . . <complete query from 0391></entry></row><row><entry>  ) asim </entry></row><row><entry> JOIN <db-schema>.global_call_put_prices scp </entry></row><row><entry> ON scp.asset_id = asim.asset_id;</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0488The expected returns for the session assets batch may be transposed into array format at <b>3669</b>. In one embodiment, the wide array format may facilitate improved performance when calculating portfolio level return metrics. For example, the expected returns for the session assets batch may be transposed into array format via an Oracle RDS on Cloud database command similar to the following: <ul id="ul0053" list-style="none"><li id="ul0053-0001" num="0000"><ul id="ul0054" list-style="none"><li id="ul0054-0001" num="0489">Custom data type asset_sim_return_data_type is used to store an array of decimal values. Each decimal value is split into two parts (e.g., X.Y where X represents the CVaR value and Y represents the market id). Storing both CVaR metric and the associated market id allows storing data in one variable instead of two thus saving storage. This also allows parallel execution of collecting returns in the array format and maintaining the market ids for which each of the returns are associated with.</li></ul></li></ul>

0000<tables id="TABLE-US-00089" num="00089"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="266pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>SELECT</entry></row><row><entry>  /*+ full(asim) parallel(asim 8) */ </entry></row><row><entry>  asim.asset_id, </entry></row><row><entry>  lc_truncatedPricingDate AS pricing_dt, </entry></row><row><entry>  CAST ( COLLECT( TO_BINARY_DOUBLE(TRUNC(asim.return_quarterly) + </entry></row><row><entry>SIGN(asim.return_quarterly)* ((asim.market_id*10) +1 )/1000000 )) AS </entry></row><row><entry>ASSET_SIM_RETURN_DATA_TYPE) return_quarterly, </entry></row><row><entry>  CAST ( COLLECT( TO_BINARY_DOUBLE(TRUNC(asim.return_biannual) + </entry></row><row><entry>SIGN(asim.return_biannual)* ((asim.market_id*10) +1 )/1000000 )) AS </entry></row><row><entry>ASSET_SIM_RETURN_DATA_TYPE) return_biannual, </entry></row><row><entry>  CAST ( COLLECT( TO_BINARY_DOUBLE(TRUNC(asim.return_yearly) + </entry></row><row><entry>SIGN(asim.return_yearly)* ((asim.market_id*10) +1 )/1000000 ) )AS </entry></row><row><entry>ASSET_SIM_RETURN_DATA_TYPE) return_yearly </entry></row><row><entry> FROM <db-schema>.global_asset_sim_tmp asim </entry></row><row><entry> GROUP BY asim.asset_id </entry></row><row><entry> ) UNPIVOT (RETURN FOR sim_id IN (return_quarterly AS 20, return_biannual AS 21, </entry></row><row><entry>return_yearly AS 22)</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0490The transposed expected returns for the session assets batch may be written to the asset simulation wide table via parallel execution (e.g., via a parallel query) at <b>3673</b>. In one implementation, the asset simulation wide table (e.g., asset_sim_wide table in <figref idref="DRAWINGS">FIG. 40</figref>) may be written to in parallel by query server processes from the utilized sessions (e.g., by up to 32 query server processes when utilizing 4 sessions with degree of parallelism of 8). For example, the transposed expected returns for the session assets batch may be written to the asset simulation wide table via parallel execution via an Oracle RDS on Cloud database command similar to the following:

0000<tables id="TABLE-US-00090" num="00090"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>INSERT INTO <db-schema>.asset_sim_wide </entry></row><row><entry> /*+ parallel(8) NO_GATHER_OPTIMIZER_STATISTICS */ </entry></row><row><entry> SELECT * </entry></row><row><entry> FROM </entry></row><row><entry>  (SELECT </entry></row><row><entry>   /*+ full(asim) parallel(asim 8) */ </entry></row><row><entry>   asim.asset_id, </entry></row><row><entry>   lc_truncatedPricingDate AS pricing_dt, </entry></row><row><entry>   CAST ( COLLECT( TO_BINARY_DOUBLE(TRUNC(asim.return_quarterly)+ </entry></row><row><entry> . . . <complete query from 3669></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0491A determination may be made at <b>3677</b> whether there remain asset return metrics to calculate for the session assets batch. In one implementation, each of the asset return metrics (e.g., requested asset return metrics specified in the asset return metrics calculation request, default asset return metrics specified in a configuration setting) may be calculated. If there remain asset return metrics to calculate, the next asset return metric may be selected at <b>3681</b>. For example, asset return metrics may include a security's expected return, worst returns (CVaR), return volatility, and/or the like.

0492The selected asset return metric for the session assets batch may be calculated via parallel execution (e.g., via a parallel query) at <b>3685</b>. For example, the average of 5% worst returns may be calculated for the CVaR asset return metric. In one implementation, the selected asset return metric for the session assets batch may be calculated in accordance with an applicable formula for the selected asset return metric. For example, the selected asset return metric (e.g., CVaR) for the session assets batch may be calculated via parallel execution via an Oracle RDS on Cloud database command similar to the following: <ul id="ul0055" list-style="none"><li id="ul0055-0001" num="0000"><ul id="ul0056" list-style="none"><li id="ul0056-0001" num="0493">The query below shows how CVaR measure is calculated in parallel based on available asset returns for a single horizon. Similar queries may be run for bi-annual and annual horizons. lc_truncatedPricingDate holds the pricing date for which the batch is run, lv_marketCount holds the number of markets used for simulations and lv_marketPercentageForCvar holds the percentage value used for calculating the CVaR (e.g., average of the worst 5% returns).</li></ul></li></ul>

0000<tables id="TABLE-US-00091" num="00091"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>SELECT</entry></row><row><entry>  /*+ parallel(8) */ </entry></row><row><entry>  lc_truncatedPricingDate pricing_dt, </entry></row><row><entry>  asim.asset_id, </entry></row><row><entry>  p_simIdQuarterly, </entry></row><row><entry>  ′CVAR′ measure_name, </entry></row><row><entry>  NULL AS factor_id, </entry></row><row><entry>  NULL AS market_id, </entry></row><row><entry>  AVG(asim.return_quarterly) measure_value </entry></row><row><entry> FROM </entry></row><row><entry>  (SELECT * </entry></row><row><entry>  FROM </entry></row><row><entry>   (SELECT asim.asset_id, </entry></row><row><entry>    asim.return_quarterly, </entry></row><row><entry>    ROW_NUMBER( ) OVER( PARTITION BY asim.asset_id </entry></row><row><entry>ORDER BY asim.return_quarterly ) rk </entry></row><row><entry>   FROM <db-schema>.global_asset_sim_tmp asim</entry></row><row><entry>   ) asim </entry></row><row><entry>  WHERE rk <= lv_marketPercentageForCvar * lv_marketCount </entry></row><row><entry>  ) asim </entry></row><row><entry> GROUP BY asim.asset_id;</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0494The selected asset return metric for the session assets batch may be written to the asset measure table via parallel execution (e.g., via a parallel query) at <b>3689</b>. In one implementation, the asset measure table (e.g., asset_measure table in <figref idref="DRAWINGS">FIG. 40</figref>) may be written to in parallel by query server processes from the utilized sessions (e.g., by up to 32 query server processes when utilizing 4 sessions with degree of parallelism of 8). For example, the selected asset return metric (e.g., CVaR) for the session assets batch may be written to the asset measure table via parallel execution via an Oracle RDS on Cloud database command similar to the following:

0000<tables id="TABLE-US-00092" num="00092"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>INSERT INTO <db-schema>.asset_measure </entry></row><row><entry /><entry> /*+ parallel(8) NO_GATHER_OPTIMIZER_STATISTICS */ </entry></row><row><entry /><entry> SELECT</entry></row><row><entry /><entry>  /*+ parallel(8) */ </entry></row><row><entry /><entry>  lc_truncatedPricingDate pricing_dt, </entry></row><row><entry /><entry>  asim.asset_id, </entry></row><row><entry /><entry>  p_simIdQuarterly, </entry></row><row><entry /><entry>  ′CVAR′ measure_name, </entry></row><row><entry /><entry> . . . <complete query from 3685></entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0495The temporary tables created for the session assets batch may be cleared at <b>3693</b>. In one embodiment, the temporary tables created for the session assets batch may be cleared to reduce temporary storage utilization. For example, the temporary tables created for the session assets batch may be cleared via an Oracle RDS on Cloud database command similar to the following:

0000<tables id="TABLE-US-00093" num="00093"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> </entry><entry>EXECUTE IMMEDIATE ′TRUNCATE TABLE </entry></row><row><entry /><entry><db-schema>.global_asset_id_distinct_tmp DROP STORAGE′;</entry></row><row><entry /><entry>EXECUTE IMMEDIATE ′TRUNCATE TABLE</entry></row><row><entry /><entry><db-schema>.global_factor_expo_tmp DROP STORAGE′;</entry></row><row><entry /><entry>EXECUTE IMMEDIATE ′TRUNCATE TABLE</entry></row><row><entry /><entry><db-schema>.global_factor_sim_tmp DROP STORAGE′; </entry></row><row><entry /><entry>EXECUTE IMMEDIATE ′TRUNCATE TABLE </entry></row><row><entry /><entry><db-schema>.global_asset_sim_tmp DROP STORAGE′;</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0496Asset return metrics data from the asset simulation wide table and/or the asset measure table may be provided to the requesting application at <b>3697</b>. In one implementation, the asset return metrics data may be provided via an asset return metrics calculation response. In some implementations, global temporary tables may be cleaned up using Data Definition Language (DDL) statements for faster execution.

0497<figref idref="DRAWINGS">FIG. 37</figref> shows an architecture for the MLPO. In <figref idref="DRAWINGS">FIG. 37</figref>, an embodiment of how the database calculation engine <b>3701</b> may be utilized to facilitate generation of a portfolio returns visualization (e.g., for constructing an optimized bond ladder portfolio) is illustrated.

0498<figref idref="DRAWINGS">FIG. 38</figref> shows an architecture for the MLPO. In <figref idref="DRAWINGS">FIG. 38</figref>, an embodiment of how the factor exposure table may be generated using parallel processing (e.g., via a parallel query) is illustrated. For example, the factor exposure table may be generated via parallel execution via an Oracle RDS on Cloud database command similar to the following:

0000<tables id="TABLE-US-00094" num="00094"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>INSERT INTO Factor Expo /*+ parallel(8) </entry></row><row><entry>NO_GATHER_OPTIMIZER_STATISTICS */</entry></row><row><entry>SELECT /*+ full(a) parallel(a 8) */ </entry></row><row><entry> case b.factor_id </entry></row><row><entry>  when 50 then -- exposure for muni 2Y </entry></row><row><entry>  when 55 then -- exposure for muni 5Y </entry></row><row><entry>  when 280 then - dimension reduction using median OAS </entry></row><row><entry>  . . . </entry></row><row><entry> end </entry></row><row><entry>FROM INST_REF_ANALYTICS_TEMP a </entry></row><row><entry>INNER JOIN SECURITYTYPE_FACTOR_TEMP b </entry></row><row><entry>on a.product_type = b.product_type</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0499<figref idref="DRAWINGS">FIG. 39</figref> shows an architecture for the MLPO. In <figref idref="DRAWINGS">FIG. 39</figref>, an embodiment of an asset return metric calculation process that may be utilized to facilitate operation of the database calculation engine is illustrated. For example, the asset return metric calculation process may be implemented via pseudocode similar to the following:

0000<tables id="TABLE-US-00095" num="00095"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Asset Return Metric Calculation Process Pseudocode</entry></row><row><entry>GET Input of range of assets to run for the sessions </entry></row><row><entry>CLEAR all temporary tables </entry></row><row><entry>FIND target assets based on filter criteria/input </entry></row><row><entry>POPULATE temporary table with factor sims for target assets </entry></row><row><entry>POPULATE temporary table with factor exposure for target assets </entry></row><row><entry>SET no-of-target-assets to total number of target assets to be processed </entry></row><row><entry>WHILE no-of-target-assets > 0 </entry></row><row><entry> FETCH next 1000 assets from target assets </entry></row><row><entry> POPULATE temporary factor sim with factors for 1K assets </entry></row><row><entry> POPULATE temporary factor expo for 1K assets </entry></row><row><entry> CALCULATE asset sims i.e. sum product of factor_sim and factor_expo </entry></row><row><entry>  for 1K assets (parallel execution) </entry></row><row><entry> TRANSPOSE asset sims in wide format by converting market returns</entry></row><row><entry>  into array format for 1K assets </entry></row><row><entry> SAVE asset sims to table (parallel execution) </entry></row><row><entry> CALCULATE CVAR in parallel for 1K assets </entry></row><row><entry> SAVE CVAR to asset measure table (parallel execution) </entry></row><row><entry> CLEAR temporary tables </entry></row><row><entry> ADJUST no-of-target-assets with number of records processed i.e.</entry></row><row><entry>  no-of-target-assets = no-of-target-assets − 1000</entry></row><row><entry>CONTINUE LOOP</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0500<figref idref="DRAWINGS">FIG. 40</figref> shows an architecture for the MLPO. In <figref idref="DRAWINGS">FIG. 40</figref>, an entity relationship diagram describing embodiments of a database with a set of database tables that may be utilized to facilitate operation of the database calculation engine is illustrated.

0501<figref idref="DRAWINGS">FIG. 41</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 41</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for constructing an optimized bond ladder portfolio is illustrated. Screen <b>4101</b> shows that a user may utilize a positions tab <b>4105</b> to specify a universe of investment securities. The user may utilize a set of strategy setting widgets <b>4110</b> to specify an investment amount, a time horizon, a rung interval, a tax rate, a yield maximization method, and/or the like. The user may utilize a set of security selection widgets <b>4115</b> to specify a tax status, a set of products (e.g., one or more of municipal, corporate, treasury, etc.), a state, a callable setting, a minimum credit rating, whether to include non-rated bonds, a maximum security exposure, and/or the like. The user may utilize a construct portfolio widget <b>4120</b> to initiate the creation of the optimized bond ladder portfolio.

0502<figref idref="DRAWINGS">FIG. 42</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 42</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for constructing an optimized bond ladder portfolio is illustrated. Screen <b>4201</b> shows that the user may utilize a positions tab <b>4205</b> to view proposed positions of the optimized bond ladder portfolio for corporate product type. The user may utilize a set of proposed positions widgets <b>4210</b> to view information regarding bond ladder rungs and/or regarding individual investment securities in each rung.

0503<figref idref="DRAWINGS">FIG. 43</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 43</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for constructing an optimized bond ladder portfolio is illustrated. Screen <b>4301</b> shows that the user may utilize a positions tab <b>4305</b> to view proposed positions of the optimized bond ladder portfolio for municipal product type. The user may utilize a set of proposed positions widgets <b>4310</b> to view information regarding bond ladder rungs and/or regarding individual investment securities in each rung.

0504<figref idref="DRAWINGS">FIG. 44</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 44</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for constructing an optimized bond ladder portfolio is illustrated. Screen <b>4401</b> shows that the user may utilize a positions tab <b>4405</b> to view proposed positions of the optimized bond ladder portfolio for treasury product type. The user may utilize a set of proposed positions widgets <b>4410</b> to view information regarding bond ladder rungs and/or regarding individual investment securities in each rung.

0505<figref idref="DRAWINGS">FIG. 45</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 45</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for constructing an optimized bond ladder portfolio is illustrated. Screen <b>4501</b> shows that the user may utilize a portfolio analysis tab <b>4505</b> to view portfolio characteristics of the optimized bond ladder portfolio with no risk score adjustment. The user may utilize a set of portfolio characteristics widgets <b>4510</b> to view information regarding the various portfolio characteristics.

0506<figref idref="DRAWINGS">FIG. 46</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 46</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for constructing an optimized bond ladder portfolio is illustrated. Screen <b>4601</b> shows that the user may utilize a portfolio analysis tab <b>4605</b> to view portfolio characteristics of the optimized bond ladder portfolio with risk score adjustment. The user may utilize a set of portfolio characteristics widgets <b>4610</b> to view information regarding the various portfolio characteristics.

0507<figref idref="DRAWINGS">FIG. 47</figref> shows a screenshot illustrating user interface(s) of the MLPO. In <figref idref="DRAWINGS">FIG. 47</figref>, an exemplary user interface (e.g., for a mobile device, for a website) for constructing an optimized bond ladder portfolio is illustrated. Screen <b>4701</b> shows that the user may view information regarding market sensitivity of the optimized bond ladder portfolio. The user may utilize a set of market sensitivity widgets <b>4705</b> to view information regarding market sensitivity of the optimized bond ladder portfolio for overall market scenarios, for specified predefined scenarios, for specified business cycles, and/or the like over various time horizons.

ADDITIONAL ALTERNATIVE EMBODIMENT EXAMPLES

0508The following alternative example embodiments provide a number of variations of some of the core principles already discussed for expanded color on the abilities of the MLPO.

0509<figref idref="DRAWINGS">FIG. 31</figref> shows an architecture for the MLPO. In <figref idref="DRAWINGS">FIG. 31</figref>, an embodiment of an AWS architecture that may be utilized to facilitate MLPO (also referred to as ATIM in the figure) operation is illustrated.

0510<figref idref="DRAWINGS">FIG. 32</figref> shows an architecture for the MLPO. In <figref idref="DRAWINGS">FIG. 32</figref>, an embodiment of an AWS architecture that may be utilized to facilitate MLPO (also referred to as ATIM in the figure) simulation calculation workflow is illustrated.

0511<figref idref="DRAWINGS">FIGS. 33A-B</figref> show an architecture for the MLPO. In <figref idref="DRAWINGS">FIGS. 33A-B</figref>, entity relationship diagrams describing embodiments of a database with a set of database tables that may be utilized to facilitate MLPO operation are illustrated.

0512<figref idref="DRAWINGS">FIG. 48</figref> shows an architecture for the MLPO. In <figref idref="DRAWINGS">FIG. 48</figref>, an embodiment of a bond ladder construction process that may utilize asset return metric data (e.g., CVaR in the asset measure table) provided by the database calculation engine is illustrated.

0513Enabling Unprecedented Market Stress Scenarios to be Generated Following the Observed Unprecedentedness Pattern from History

0514The unprecedentedness of a historical scenario is described as the number of Δ factors that take unprecedented values compared to historical scenarios prior to that date. The plot in <figref idref="DRAWINGS">FIG. 65</figref> visualizes the relationship between ΔVIX and historical unprecedentedness. In this example, a degree 2 polynomial is used to represent the relationship because as ΔVIX becomes more extreme in both ends, greater number of Δ factors taking unprecedented values are expected to show up. The fitted degree 2 polynomial curve is the historical unprecedentedness curve.

0515As shown in <figref idref="DRAWINGS">FIG. 65</figref>, a large VIX change comes with unseen changes in market risk factors.

0516The unprecedentedness of a transfer-layer VAE simulated scenario is described to be the number of Δ factors that take unprecedented values compared to historical scenarios. The plot in <figref idref="DRAWINGS">FIG. 66</figref> shows that simulation output from transfer-layer VAE fails to reflect the relation shown above, with almost all scenarios having 0 unprecedentedness. The reason is that VAE restores the historical scenarios very well so it is not surprising we are unable to see more extreme Δ factors values.

0517As shown in <figref idref="DRAWINGS">FIG. 66</figref>, a Deep Learning Model captures each factor's history closely but neglects other factors' related new extremes.

0518Following what has been done to calculate VAE unprecedentedness, we can apply it to panic simulated market scenarios. The goal is to make the relationship between ΔVIX and stress sim unprecedentedness to look alike to the relationship in historical unprecedentedness section. The approach is to find the mean squared error between the unprecedentedness curves. See <figref idref="DRAWINGS">FIGS. 68, 69, and 70</figref>.

0519For example, as shown in <figref idref="DRAWINGS">FIG. 67</figref>, by selecting historical scenarios with either ΔVIX<−1000 or ΔVIX>3062 to compute mean and covariance and then fit a multivariate normal distribution and sample the same number of scenarios as in history, the relationship fitted from simulated scenarios will be alike to the historical.

0520A component of the market scenario simulation is a deep learning model, variational autoencoder. To take advantage of the cloud compute power, in one implementation, a machine learning service, SageMaker, may be used in AWS. SageMaker is a fully managed service that provides an efficient way for developers and data scientists to collaborate together to build, train, tune, and deploy models in a machine learning pipeline. With SageMaker, the model training and tuning process can be conveniently run in a parallel and distributed way on multiple instances and multiple GPUs. In addition, the one-click deployment feature of SageMaker significantly reduces the effort to deploy a machine learning model. For example, with the parallel computing architecture using SageMaker, the training time of multiple models may be reduced to 2 minutes in total, while training multiple models sequentially with single instance and single CPU takes 45 minutes, as shown in <figref idref="DRAWINGS">FIG. 72</figref>.

0521Simulating Mutual Fund and ETF Asset Returns

0522The Mutual Fund and ETF returns simulation model employs a set of machine learning techniques to estimate 3-month, 6-month and 1-year returns under simulated market scenarios while allowing for domain experts to incorporate their subjective views. <figref idref="DRAWINGS">FIG. 49</figref> illustrates the overall model architecture. In one implementation, parallel computing may be used to implement training and deployment of a unique model for each mutual fund or ETF. As <figref idref="DRAWINGS">FIG. 50</figref> demonstrates, the process of loading data from database tables, performing feature engineering, training model and writing results to database may be distributed to multiple processors and conducted simultaneously. <figref idref="DRAWINGS">FIG. 51</figref> summarizes the database tables containing model input and output. For each fund or ETF, the returns during specified investment horizons are aggregated geometrically from daily returns. Domain experts have the option of specifying a pool of potential market factors to be considered by the feature selection procedure for a particular fund or ETF. If no factors are specified by experts, available market factors will be considered. To select the set of market factors that contribute the most to overall model performance and mitigate the problem of multicollinearity, a proprietary feature selection procedure is designed to utilize XGBoost to rank the feature importance levels of available market factors, and feed the factors with positive importance scores to a customized forward selection process, which selects a set of factors that maximizes the model's adjusted R-squared as well as restrains model coefficients from changing signs (see <figref idref="DRAWINGS">FIG. 52</figref>). Subsequently, a Ridge Regression model is trained to learn the relationship between a fund's or ETF's historical returns and those of the selected set of market factors using 75% of historical data points, is validated using the remaining 25% of historical data points based on a number of metrics, including out-of-sample adjusted R-squared, effect size of residual distribution, residual correlation, etc., and is utilized to estimates its returns under stimulated market environments. <figref idref="DRAWINGS">FIG. 53</figref> illustrates the market risk factor exposures based on the regression models as presented in the UI. To account for a fund or ETF's active risk not captured by common market factors, regression residuals from the model validation stage are randomly sampled and added to the simulated fund or ETF returns. Lastly, the estimated returns may be calibrated to reflect capital market assumptions provided by economists. <figref idref="DRAWINGS">FIGS. 54 and 55</figref> present the distributions of simulated returns under user-defined market scenarios and different business cycles, respectively.

0523Simulating Equity Asset Returns

0524Individual Equity returns for different time horizons are aggregated geometrically with daily return, which is adjusted for corporate actions such as stock split and dividend. Daily return may be used instead of price because price can have huge jump caused by corporate actions. Feature selection may be utilized before model training. It uses an XGBoost model to select a subset of features that contribute to positive gain in feature importance ranking and then feeds these selected features to a forward selection process, which further extracts features that improve adjusted R square (see <figref idref="DRAWINGS">FIG. 56</figref>). Both Ridge regression (e.g., used in forward selection with adjusted R square) and XGBoost regression at the last step deal with multi-collinearity problem. Based on the CAPM model, an asset's risk has 2 components: one is market risk driven, one is idiosyncratic risk driven. Building the 2 parts separately allows models to better capture the behavior of different risk components. Intuition for conditional beta modeling is that based on historical observation, equities' correlation to market index can vary under different market scenarios, and correlation from different equities can also vary. Conditional beta model captures individual equity's sensitivity to market index across the simulated market scenarios and formulates the market risk driven part. Intuition for idiosyncratic risk modeling is that based on historical observation, beta risk from broad market index partially explains an equity's total return, and the other key part is company specific risk, which in this case is revealed from company financials data and default probability. Combining conditional beta model and idiosyncratic risk model, a more comprehensive total risk simulation is generated matching the CAPM's explanation. During training phase, realized beta is calculated using linear regression of individual equity's return series against market index's return series for a selected time horizon. Modeling for 3M, 6M, and 12M are separated since market scenario simulation and financials factors capture their own dependencies under different time horizons. To account for residual analysis, a few validations were done. 1. Effective size (Cohen's D measure) was close to zero. 2. Residual correlation to target variable was close to zero. 3. Residual was unbiased. Residuals are stored during training phase, randomly sampled during scoring phase, and added to simulated conditional beta to better capture market driven risk. Conditional beta modeling uses broad common market risk factors as features, including macro factors, equity indices, and smart beta factors. To simulate individual equity's conditional beta against market index, simulated market scenarios are used. Conditional beta modeling may be implemented with parallel computing on EMR notebook, which uses AWS cloud environment and utilizes clusters to do the training. Generated models for each individual equity may be directly written into a Postgres database in binary format through a driver (see <figref idref="DRAWINGS">FIG. 62</figref>). Company specific returns are modeled with feature importance weighted historical sampling. During model training phase, feature importance is stored. During scoring phase, if a simulated market scenario can be mapped to individual equity's existing historical scenario, then the excess return over market index for this specific historical scenario is used. Otherwise, a Euclidian distance is calculated weighted by feature importance from selected risk features, and excess return over market index for the closest historical scenario is used. Total return is calculated combining beta return and idiosyncratic return. Simulated returns for each equity are stored in an array format in Postgres table.

0525EMR Notebook is used in simulating asset returns concurrently on Cloud Technology platform for mutual funds, ETFs, equities and fixed income instruments. In Financial Services Industry, as data sets grow rapidly and complexly, the data transformation, data storage, and the users' real-time operations end up with a huge burden. Big data frameworks may be employed to support the data process and storage, and they allow the data to be generated and stored in a parallel and distributed way. Spark and Hadoop are examples of compute engines for big data that may be utilized. The principle of the compute engine in Spark is to analyze computation tasks and optimize the workflow of the data processing before actually executing the code. Spark may utilize Directed Acyclic Graph (DAG) optimizations and in memory processing.

0526Spark has been integrated into many cloud services, such as Elastic Map Reduce (EMR) provided by Amazon Web Service (AWS). In one implementation, EMR may be utilized to make full usage of compute power offered by the cloud provider and save compute costs, since the EMR runtime for Spark can be over 3 times faster than standard Spark. Using cloud provided service may help to improve the performance of workloads without making extra changes to the applications.

0527In one implementation, in order to improve the development efficiency, EMR Notebooks may be used along with EMR clusters to submit Spark jobs for parallel computing. EMR Notebook is a managed notebook environment which is based on the open-source Jupyter notebook. It supports submitting Spark code to EMR clusters through Apache Livy.

0528In one implementation, the Optimizer is developed based on parallel computation capability and advanced numerical optimization methodologies, such as Tail Risk Optimizer and Mean-Variance Optimizer, in order to provide optimal portfolio within 3M, 6M and 1Y horizon and user specified conditions. It evaluates the portfolio expected return, portfolio volatility and portfolio drawdown, equipped with flexible scenarios choices and business Cycle overview.

0529For Tail Risk Optimizer, mixed integer programming, binary integer programming and linear programming with rounding techniques are available. CVaR-Mean frontier can be shaped with the optimizer parallel computation ability and then illustrate the relationship between CVaR and expected return. Different CVaR-Mean frontier can be visualized according to diversification preferences (see <figref idref="DRAWINGS">FIG. 71</figref>) and market scenarios. The mixed integer programming can offer more accurate results according to asset price and asset tradable amount while the linear programming with rounding techniques guarantees faster performance on large scale computation (See <figref idref="DRAWINGS">FIG. 72</figref>).

0530For the Mean-Variance Optimizer, the portfolio risk is measured by covariance matrix that can be estimated through two different methods in the tool. “Shifted Diagonal” method adjusts original sample covariance matrix diagonal to decrease asset correlation influence in optimization, and “Ledoit-Wolf” method gives a robust estimation by minimizing the quadratic loss function.

0531In one implementation, the optimizer attempts to maximize the portfolio return with a risk penalty whose value is decided by risk tolerance parameter. The 0 risk tolerance will lead the optimizer to minimize the risk at all costs and the infinity risk tolerance will maximize the return at all costs. In the tool, the risk tolerance has been mapped from 0 to 10 to be user friendly.

0532Similarly, the efficient frontier of Mean Variance Optimizer can be presented according to investors' preferences as well as various market scenarios. Optimal portfolio weights may be generated varying risk aversion in the convex optimization with user specified weights constrains and market scenario. This set of optimal solutions the optimizer generated would form a frontier line and the optimal solution of current risk tolerance level would be a big red dot on the previous frontier and should move along on the efficient frontier when risk tolerance parameter changes (see <figref idref="DRAWINGS">FIG. 73</figref>). Thus, the change of risk tolerance level may not change the efficient frontier shape, but the changes of diversification and market scenarios may lead to a reshaped efficient frontier (see <figref idref="DRAWINGS">FIG. 74</figref> and <figref idref="DRAWINGS">FIG. 75</figref>).

0533Multi-Risk Factor Risk Engine and Portfolio Aggregation Using Oracle RDS on Cloud

0534Using Oracle RDS on Cloud, a SQL-based solution effectively utilizes different parallel execution techniques for calculating simulation data. Conditional risk simulation can now be calculated for over a million assets using a faster, simple, cost effective and scalable solution using Oracle RDS on Cloud in substantially less amount of time. Computations happens on the database server, eliminating having to transfer a huge set of data to external systems for processing and therefore maximizes processing of data using cloud computing.

0535The first step of the process is to calculate Factor Exposures for available assets as shown in <figref idref="DRAWINGS">FIG. 76</figref>. Based on available reference data and analytics, the spread ratio is calculated for the available assets in parallel. The second step is to calculate simulated returns for the available assets as shows in <figref idref="DRAWINGS">FIG. 77</figref>. The process of generating simulated asset returns may involve, getting unique list of assets for which exposure data is available and loading the factor exposures for assets with exposure to the factors and loading factor simulations for those factors (see <figref idref="DRAWINGS">FIG. 78</figref>). The process then splits the workload into smaller chunks with each chunk processing a subset of the assets. The simulated returns for the assets are then calculated, adjusted using available call and put schedule, and written to the database using several parallel computing techniques as listed below (see <figref idref="DRAWINGS">FIG. 79</figref>).

0536Convexity Adjustment—To integrate the impact of convexity in asset simulation, it may be included as an additional term in the dot product following these steps. The convexity metric (option adjusted convexity) is obtained from Sentinel's security_master table.

0000Step 1: Insert convexity as two new “factors” (id 80 for non-muni instruments, 81 for muni instruments) in the factor_expo table (see <figref idref="DRAWINGS">FIG. 80</figref>). <br /> Step 2: For each simulation id and each market scenario (market id), insert the square of the change in yield as two new “factors” (id 80 for Treasury curves, 81 for muni curves) in the factor_sim table. In one implementation, the average return of different key rates may be used as the proxy for the change in yield (see <figref idref="DRAWINGS">FIG. 81</figref>).

0537Treasury curves 3M, 6M, 1Y, 2Y, 3Y, 5Y, 7Y, 10Y, 20Y, 30Y

0538Muni curves 2Y, 5Y, 10Y, 20Y

0539Optionality Adjustment—If an instrument has an embedded call (or put) option redeemable within the investment horizon, the return from exercising the call (or put) option may be set as the upper (or lower) bound of the simulated asset return. The call (or put) option schedules, including redemption dates and prices, are obtained from Sentinel's call_schedule (or put_schedule) tables (see <figref idref="DRAWINGS">FIG. 82</figref>).

0540In one implementation, several data reduction, scaling and parallel computing techniques may be utilized. For example, innovative ways to use global temporary tables and sessions, data reduction techniques to drastically limit amount of data utilized for processing thus lowering processing time, and several other data parallelization techniques for generating simulation data may be utilized.

00001. Use of Multiple Batches to achieve higher degree of parallelism (DOP) <br /> 2. Use of Global Temporary Tables (GTT) to be able to run batch in multiple sessions and reduce temporary storage requirements <br /> 3. Use of Data Reduction techniques to reduce full table scans for joins between Factor Exposure and Factor Simulation table <br /> 4. Use of Parallel Query to parallelize generation of Asset Simulation and Contribution to Value at Risk data <br /> 5. Use of Parallel DML to parallelize inserting data related to Asset Simulation and Contribution to Value at Risk <br /> 6. Use of DDL for faster execution of delete statements to speed up cleanup of global temporary tables (see <figref idref="DRAWINGS">FIG. 79</figref>)

0541Tail-Risk Adjusted Bond Ladder Construction

0542Tail-risk adjusted bond ladder construction is the capability to construct a bond ladder incorporating real-time market offerings, user-defined search criteria, and pre-trade scenario risk analysis (see <figref idref="DRAWINGS">FIG. 93</figref>). In some implementations, the tail-risk adjusted bond ladder construction process is a rule based approach that avoids the use of a solver, which allows a large number of bond market offerings to be evaluated in real-time, guarantees portfolio construction solutions based on market offerings, and provides consistent and scalable calculation performance. The bond-ladder construction logic (see <figref idref="DRAWINGS">FIG. 88</figref>) uses the real-time bond offering from electronic bond trading venues. Real-time data fusion technologies provide the list of bonds and prices from multiple sources of liquidity. The logic also ensures the market values across the rungs of the bond ladder are approximately equal (see <figref idref="DRAWINGS">FIG. 94</figref>). The proposed bond ladder is built with approximately equal market values across the different rungs of the bond ladder (see <figref idref="DRAWINGS">FIG. 95</figref>). Market value is calculated using allocated par amount and prices from real-time bond offerings.

0543In one implementation, the bond ladder construction may use two separate modes—Yield Maximization and Risk Score Adjusted to construct the ladder (see <figref idref="DRAWINGS">FIG. 93</figref>). Under Yield Maximization mode (see <figref idref="DRAWINGS">FIG. 96</figref>), the offerings are first organized into classifications according to product type, credit rating, and final maturity. The classifications can then be further screened by user-defined search criteria resulting with the (e.g., one hundred) highest yielding securities presented per rung as ladder portfolio options. Ladder options may be allocated within the portfolio up to a user-defined diversification constraint (“Maximum Security Exposure”). By doing this, the user can specify that the market value of any individual position should not exceed a percentage threshold of the total market value of the portfolio. Under Risk Score Adjusted mode (see <figref idref="DRAWINGS">FIG. 97</figref>), the offerings are first organized into classifications according to product type, credit rating, and final maturity. The classifications can then be further screened by user-defined search criteria. The resulting set of securities are then run through the model which takes the offering yield to worst and performs a calculation on each to arrive at a down-side risk score. Down-side risk is quantified using a statistical measure calculated as a zscore, sourced from either the security's default probability or its 5% worst mark-to-market estimated total returns, also known as the 5% conditional value-at-risk (CVaR).

0544For bonds which are covered by Kamakura Corporation's default risk model, default probabilities may be used as the down-side risk score. Default probabilities are published daily by Kamakura for public, private and sovereign issuers across multiple time horizons. Default probabilities may be updated for these issuers using the following tenors: 1 Month, 3 Months, 6 Months, 1 Yr, 2 Yr, 4 Yr, 5 Yr, 7 Yr, 10 Yr. These time horizons are matched with the time to maturities of the bonds in the bond offerings. For bonds not covered by Kamakura's default risk model, down-side risk may be quantified as CVaR calculated based on a proprietary risk model. A normalized risk score is calculated for available bond offerings for each rung. The bonds' yield to worst may be adjusted by the risk score. Bond offerings with lower down-side risk rank higher; bond offerings with higher risk rank lower.

0545Steps for Tail-Risk Adjusted Bond Ladder Construction

00001. Get Available Bonds from Offers API based on inputs provided in the Strategy Settings and Security Selected screen of Bond Beacon (see <figref idref="DRAWINGS">FIG. 89</figref>) <br /> 2. Check if Risk Score Adjustment option is selected as the Yield Maximization Method. If Yes, continue with Step #3 below otherwise, continue to Step #5. <br /> 3. Calculate and store MEAN and STDDEV based on data available for Conditional Value at Risk (CVAR) and Default Probability. These values will be used later to calculate z-score and adjustment to yield. <br /> 4. Check each security available for allocation and adjust their yield

0546a. If the security has default probability, calculate z-score using the following formula

0000<br /><i>z</i>-score=(DEFAULTinstrument−DEFAULTmean)/DEFAULTstddev

0000<br />Adjusted Yield=yield*(1<i>−z</i>−score/10)

0547b. If no default probability data is available for the security, calculate z-score based on the following formula

0000<br /><i>z</i>-score=(CVARinstrument−CVARmean)/CVARstddev

0000<br />Adjusted Yield=yield*(1+<i>z</i>-score/10)

00005. Run the bond allocation logic based on Adjusted Yield. If No Risk Score Adjustment option is selected, Adjusted Yield equals to the Yield of the security (see <figref idref="DRAWINGS">FIG. 90</figref> for output generated from the bond ladder construction logic).

0548a. Sort available bonds based on Adjusted Yield, Rating and Available Quantity to Trade

0549b. Calculate Quantity to Allocated in PAR for security based on Minimum Denomination, Minimum Increment and Diversification Limit (in MV)

0550c. Check for Minimum Balance Remaining based on Calculated Quantity to Allocate. If Minimum Balance Remaining Condition is not satisfied, skip the bond and continue.

0551d. Check if the rung has enough cash for allocation based on allocated MV for security. <ul id="ul0057" list-style="none"><li id="ul0057-0001" num="0000"><ul id="ul0058" list-style="none"><li id="ul0058-0001" num="0552">i. If rung has enough cash, allocate and adjust rung MV</li><li id="ul0058-0002" num="0553">ii. If run does not have enough cash, repeat step 5.a using available rung's cash as the limit. Continue with steps 5.a, 5.b and 5.c. <br /> 6. Check if Residual Cash is remaining after Bond Allocation </li></ul></li></ul>

0554a. Find Rung with highest yield. <ul id="ul0059" list-style="none"><li id="ul0059-0001" num="0000"><ul id="ul0060" list-style="none"><li id="ul0060-0001" num="0555">i. Using bonds currently allocated within a rung, find the yield based on weighted average calculations.</li><li id="ul0060-0002" num="0556">ii. Find the rung with the highest average yield.</li></ul></li></ul>

0557b. For all bonds currently available in the rung, run the bond allocation logic as listed in Step #5

0558Scenario-Based Risk Reporting for Multiple User-Specified Scenarios

0559Scenario-based Risk Reporting may be implemented as part of an application programming interface (API) which uses parallel processing for calculating risk-based analytics for user specified scenarios.

0560The first step of the process is to load simulated returns for available securities in parallel (see <figref idref="DRAWINGS">FIG. 83</figref>). If simulated returns are not available for the specified securities (see <figref idref="DRAWINGS">FIG. 91</figref>), a real-time asset simulation process is executed. This real-time process generates the simulated returns for the securities in real-time by applying data reduction methods for loading factor exposures and simulated factor returns from the database (see <figref idref="DRAWINGS">FIG. 87</figref>) for the factors the securities has exposures to. The data reduction method reduces the data loaded for calculating the simulated returns by reducing the data to the factors the securities have exposures to. This eliminates redundant data being loaded and supports the factor executing of dot product calculations utilized for generating the simulated returns (see <figref idref="DRAWINGS">FIG. 86</figref>).

0561The second step is to filter out markets based on the input scenarios (occurrence of a situation or changes to key factor such as, change in interest rates) or business cycles (a business cycle is the natural rise and fall of economic growth that occurs over time) specified by the user. For example, if user has created a scenario with a criteria in which the U.S. 2 Year Treasury Rate is between 0.3 and 1.8%, the process creates a map of markets for which the simulated returns for securities falls within this range. The process is executed in parallel for available user-defined scenarios and specified securities. If a particular user-defined scenario has multiple such criteria, additional filter logic is applied on top of previously filtered markets. Once the target list of markets is available for each user-defined scenario, the process filters the simulated returns for securities and reduces the data to the targeted markets available.

0562The final step is to calculate the weighted average simulated returns for the filtered markets based on the weight specified as part of the input for each security. The process then calculates risk-level analytics such as, CVAR based on filtered simulated returns. The results are then presented to the user (see <figref idref="DRAWINGS">FIG. 92</figref>). <figref idref="DRAWINGS">FIG. 98</figref> shows the Market Sensitivity Chart that shows how a particular portfolio performs under different user-defined scenarios and business cycles.

0563Additional embodiments may include:

Generate Simulated Market Scenarios Using a Set of Deep Learning Neural Networks and Multivariate Mixture with Cloud Computing

0000<ul id="ul0061" list-style="none"><li id="ul0061-0001" num="0564">1. A machine learning portfolio generating apparatus, comprising:</li><li id="ul0061-0002" num="0565">a memory;</li><li id="ul0061-0003" num="0566">a component collection in the memory;</li><li id="ul0061-0004" num="0567">a processor disposed in communication with the memory and configured to issue a plurality of processor-executable instructions from the component collection, the processor-executable instructions structured as: <ul id="ul0062" list-style="none"><li id="ul0062-0001" num="0568">generate, via at least one processor, a set of simulated market scenarios using a variational autoencoder with cloud computing technology, the variational autoencoder structured as: <ul id="ul0063" list-style="none"><li id="ul0063-0001" num="0569">use neural networks as encoder to generate a set of latent variables, simulate latent variables with neural networks as decoder such that the decoded simulated market scenarios follow dynamic dependencies and volatilities of historical market risk factors;</li><li id="ul0063-0002" num="0570">use a transfer layer between the encoder and the decoder to allow latent space variables to take on any distributions and any dependency joint distribution structures;</li><li id="ul0063-0003" num="0571">in which the number of latent space variables, the number of neurons in the encoder and the decoder and the number of layers of the encoder and the decoder are tuned to ensure an overall goodness of fit between the set of simulated market scenarios and a set of historical market scenarios.</li></ul></li></ul></li><li id="ul0061-0005" num="0572">2. The apparatus of embodiment 1, further, comprising:</li><li id="ul0061-0006" num="0573">the instructions from cloud computing technologies to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0064" list-style="none"><li id="ul0064-0001" num="0574">determine, via at least one processor, a historical data set, a rolling window period length, and a set of market factors;</li><li id="ul0064-0002" num="0575">determine, via at least one processor, a set of rolling window periods using the historical data set and the rolling window period length; and</li><li id="ul0064-0003" num="0576">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0065" list-style="none"><li id="ul0065-0001" num="0577">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0061-0007" num="0578">3. The apparatus of embodiment 2, further, comprising:</li><li id="ul0061-0008" num="0579">the instructions with cloud computing technologies to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0066" list-style="none"><li id="ul0066-0001" num="0580">determine, via at least one processor, the delta between values of the market factor at a beginning time point and an ending time point of the rolling window period.</li></ul></li><li id="ul0061-0009" num="0581">4. The apparatus of embodiment 3, further, comprising:</li><li id="ul0061-0010" num="0582">the processor-executable instructions on cloud computing clusters structured as: <ul id="ul0067" list-style="none"><li id="ul0067-0001" num="0583">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0067-0002" num="0584">impute, via at least one processor, the unavailable historical data for the time point using a machine learning method, the imputed delta of historical market factors structured to minimize the Mean Absolute Difference between correlation matrices of original and imputed data, in which the mean z-scores of market factor deltas with imputation are minimized compared to the mean z-scores of the original market factor deltas without imputation, and in which the ratios of the standard deviation of each factor with and without imputation approach 1.</li></ul></li><li id="ul0061-0011" num="0585">5. The apparatus of embodiment 1, further, comprising:</li><li id="ul0061-0012" num="0586">the processor-executable instructions on cloud computing clusters structured as: <ul id="ul0068" list-style="none"><li id="ul0068-0001" num="0587">utilize a deep learning neural network for a time period bucket, the trained deep learning neural network is trained to generate a set of Gaussian mixture latent variables.</li></ul></li><li id="ul0061-0013" num="0588">6. The apparatus of embodiment 5, further, comprising:</li><li id="ul0061-0014" num="0589">the processor-executable instructions on cloud computing clusters structured to generate simulated market scenarios for the time period bucket, using the trained deep learning neural network associated with the time period bucket.</li><li id="ul0061-0015" num="0590">7. The apparatus of embodiment 6, further, comprising:</li><li id="ul0061-0016" num="0591">the instructions to generate simulated market scenarios for the time period bucket are structured to comprise instructions to: <ul id="ul0069" list-style="none"><li id="ul0069-0001" num="0592">generate, via at least one processor, a set of random values for the set of Gaussian mixture latent variables; and</li><li id="ul0069-0002" num="0593">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, from the generated set of random values using a neural network decoder of the trained deep learning neural network associated with the time period bucket.</li></ul></li><li id="ul0061-0017" num="0594">8. The apparatus of embodiment 1, further, comprising:</li><li id="ul0061-0018" num="0595">the processor-executable instructions structured as: <ul id="ul0070" list-style="none"><li id="ul0070-0001" num="0596">filter, via at least one processor, the set of simulated market scenarios associated with a time period length based on specified ranges of allowable values for specified customized market factors.</li></ul></li><li id="ul0061-0019" num="0597">9. The apparatus of embodiment 1, further, comprising:</li><li id="ul0061-0020" num="0598">the processor-executable instructions structured as: <ul id="ul0071" list-style="none"><li id="ul0071-0001" num="0599">filter, via at least one processor, the set of simulated market scenarios associated with a time period length based on specified business cycle settings.</li></ul></li><li id="ul0061-0021" num="0600">10. The apparatus of embodiment 1, further, comprising:</li><li id="ul0061-0022" num="0601">the instructions to train a machine learning process to generate unprecedented stress market scenarios structured as: <ul id="ul0072" list-style="none"><li id="ul0072-0001" num="0602">quantify unprecedentedness as a fitted polynomial degree 2 curve, via at least one processor on cloud computing infrastructure, which captures the relationship between movements in VIX and the number of risk factors that experienced unprecedented magnitude of changes; and</li><li id="ul0072-0002" num="0603">train, via at least one processor on cloud computing platform, the conditional dependency structure of large movements in VIX, <ul id="ul0073" list-style="none"><li id="ul0073-0001" num="0604">in which the VIX up and VIX down levels are solved by the objective function of minimizing the mean squared error between a simulated polynomial degree 2 curve and a historical polynomial degree 2 curve,</li><li id="ul0073-0002" num="0605">in which the fitted polynomial degree 2 curve is fitted from simulated market scenarios generated using at least one of: a variational autoencoder deep learning model, a gaussian copula conditional on large VIX movements.</li></ul></li></ul></li><li id="ul0061-0023" num="0606">11. The apparatus of embodiment 1, further, comprising:</li><li id="ul0061-0024" num="0607">the processor-executable instructions structured as: <ul id="ul0074" list-style="none"><li id="ul0074-0001" num="0608">apply cloud service, Amazon Web Services (AWS) SageMaker, to train, tune, and deploy deep learning models in a parallel and distributed way on multiple instances and multiple GPUs.</li></ul></li><li id="ul0061-0025" num="0609">12. The apparatus of embodiment 1, further, comprising:</li><li id="ul0061-0026" num="0610">the processor-executable instructions structured as: <ul id="ul0075" list-style="none"><li id="ul0075-0001" num="0611">use a machine learning service, SageMaker, in AWS to manage machine learning pipeline.</li></ul></li><li id="ul0061-0027" num="0612">13. The apparatus of embodiment 1, further, comprising:</li><li id="ul0061-0028" num="0613">the processor-executable instructions structured as: <ul id="ul0076" list-style="none"><li id="ul0076-0001" num="0614">utilize SageMaker to support collaboration between developers and data scientists.</li></ul></li><li id="ul0061-0029" num="0615">14. The apparatus of embodiment 1, further, comprising:</li><li id="ul0061-0030" num="0616">the processor-executable instructions of using SageMaker for parallel market scenario simulation structured as: <ul id="ul0077" list-style="none"><li id="ul0077-0001" num="0617">create a SageMaker notebook instance with specific lifecycle configuration, permissions and encryption, and network settings;</li><li id="ul0077-0002" num="0618">upload input data to S3 by providing a S3 path;</li><li id="ul0077-0003" num="0619">configure a training job as an estimator by providing arguments including at least one of: training script entry point, SageMaker execution role, number and type of training instance, security key, and a set of hyperparameters;</li><li id="ul0077-0004" num="0620">trigger the training job by launching a docker container on EC2 instances with prebuilt SageMaker docker images and downloading the input data from the specified S3 path to start the training process;</li><li id="ul0077-0005" num="0621">repeat the training job on market scenarios with different delta length to configure multiple training jobs such that they can be triggered together and trained on multiple instances in a parallel way;</li><li id="ul0077-0006" num="0622">deploy models as multiple SageMaker endpoints by specifying instance type and number of instances used to host the endpoints; and</li><li id="ul0077-0007" num="0623">simulate market scenarios with different delta length using the SageMaker endpoints.</li></ul></li></ul>

Simulating Mutual Fund and ETF Returns with Machine Learning and Cloud Computing Techniques

0000<ul id="ul0078" list-style="none"><li id="ul0078-0001" num="0624">1. A machine learning mutual fund and ETF returns simulating apparatus, comprising:</li><li id="ul0078-0002" num="0625">a memory;</li><li id="ul0078-0003" num="0626">a component collection in the memory;</li><li id="ul0078-0004" num="0627">a processor disposed in communication with the memory and configured to issue a plurality of processor-executable instructions from the component collection, the processor-executable instructions structured as: <ul id="ul0079" list-style="none"><li id="ul0079-0001" num="0628">obtain, via at least one processor, mutual funds' or ETFs' historical daily returns data sets, a set of rolling window period lengths, and data sets for a set of market factors' historical returns during the specified set of rolling window periods;</li><li id="ul0079-0002" num="0629">compute, via at least one processor, for each mutual fund or ETF, returns during each rolling window period from the set of rolling window periods, by aggregating the historical returns;</li><li id="ul0079-0003" num="0630">learn, via at least one processor, for each mutual fund or ETF, for each rolling window period from the set of rolling window periods, the respective mutual fund's or ETF's relationships with a set of most relevant market factors from their historical returns;</li><li id="ul0079-0004" num="0631">simulate, via at least one processor, for each mutual fund or ETF, for each rolling window period from the set of rolling window periods, the respective mutual fund's or ETF's returns under simulated market scenarios;</li><li id="ul0079-0005" num="0632">visualize real-time, via at least one processor, for each mutual fund, ETF, or portfolio of mutual funds and ETFs, for each rolling window period from the set of rolling window periods, the respective mutual fund's, ETF's, or portfolio's simulated returns distributions under user-specified market scenarios or business cycles; and</li><li id="ul0079-0006" num="0633">illustrate, via at least one processor, for each mutual fund or ETF, for each rolling window period from the set of rolling window periods, the respective mutual fund's or ETF's exposure to each market factor.</li></ul></li><li id="ul0078-0005" num="0634">2. The apparatus of embodiment 1, further, comprising:</li><li id="ul0078-0006" num="0635">the processor-executable instructions structured as: <ul id="ul0080" list-style="none"><li id="ul0080-0001" num="0636">construct, via at least one processor, from a set of market factor pairs, a set of spread factors, by computing the difference in returns between each pair of market factors under simulated market scenarios, the set of spread factors comprising orthogonal features that mitigate multicollinearity;</li><li id="ul0080-0002" num="0637">update, via at least one processor, the set of market factors to include the set of spread factors; and</li><li id="ul0080-0003" num="0638">select, via at least one processor, for each mutual fund or ETF, the set of most relevant market factors to utilize during simulation model training.</li></ul></li><li id="ul0078-0007" num="0639">3. The apparatus of embodiment 2, further, comprising:</li><li id="ul0078-0008" num="0640">the processor-executable instructions structured as: <ul id="ul0081" list-style="none"><li id="ul0081-0001" num="0641">obtain, via at least one processor, from database tables, for each mutual fund or ETF, domain experts' input that specifies a set of utilization market factors to be considered for utilization in the return-simulating model, based on the fund or ETF's asset category;</li><li id="ul0081-0002" num="0642">evaluate, via at least one processor, for each mutual fund or ETF, for each market factor in the set of utilization market factors, the importance level of the market factor's impact on the mutual fund's or ETF's returns, using XGBoost's feature importance measurement; and</li><li id="ul0081-0003" num="0643">select, via at least one processor, for each mutual fund or ETF, from the domain-expert-specified or entire set of market factors, the top contributing market factors to be later utilized in the return-simulation model, using a customized forward selection algorithm that maximizes regression models' adjusted R²and restrains model coefficients from flipping signs, the top contributing market factors selected to alleviate multicollinearity.</li></ul></li><li id="ul0078-0009" num="0644">4. The apparatus of embodiment 3, further, comprising:</li><li id="ul0078-0010" num="0645">the processor-executable instructions structured as: <ul id="ul0082" list-style="none"><li id="ul0082-0001" num="0646">train, via at least one processor, for each mutual fund or ETF, for each rolling window period from the set of rolling window periods, using the selected set of market factors, a ridge regression model which regularizes regression coefficients and mitigates multicollinearity;</li><li id="ul0082-0002" num="0647">evaluate, via at least one processor, for each mutual fund or ETF, for each rolling window period from the set of rolling window periods, model performance by measuring adjusted R²and conducting residual distribution analysis; and</li><li id="ul0082-0003" num="0648">store, via at least one processor, for each mutual fund or ETF, for each rolling window period from the set of rolling window periods, a binary format of the trained ridge regression model and model performance evaluation metrics in one or more database tables.</li></ul></li><li id="ul0078-0011" num="0649">5. The apparatus of embodiment 4, further, comprising:</li><li id="ul0078-0012" num="0650">the processor-executable instructions structured as: <ul id="ul0083" list-style="none"><li id="ul0083-0001" num="0651">simulate, via at least one processor, for each mutual fund or ETF, for each rolling window period from the set of rolling window periods, the returns under the simulated market scenarios, using the trained ridge regression model;</li><li id="ul0083-0002" num="0652">adjust, via at least one processor, for each mutual fund or ETF, for each rolling window period from the set of rolling window periods, the respective mutual fund's or ETF's market-factor-based simulated returns for idiosyncratic risk, by adding sampled regression residuals; and</li><li id="ul0083-0003" num="0653">calibrate, via at least one processor, for each mutual fund or ETF, for each rolling window period from the set of rolling window periods, the respective mutual fund's or ETF's returns to forward-looking capital market assumptions.</li></ul></li><li id="ul0078-0013" num="0654">6. The apparatus of embodiment 5, further, comprising:</li><li id="ul0078-0014" num="0655">the processor-executable instructions structured as: <ul id="ul0084" list-style="none"><li id="ul0084-0001" num="0656">calculate, via at least one processor, for each mutual fund or ETF, for each rolling window period from the set of rolling window periods, the correlation between the sampled regression residuals and a target variable;</li><li id="ul0084-0002" num="0657">evaluate, via at least one processor, for each mutual fund or ETF, for each rolling window period from the set of rolling window periods, a distribution of the sampled regression residuals by conducting the Mann-Whitney U Test;</li><li id="ul0084-0003" num="0658">assess, via at least one processor, for each mutual fund or ETF, for each rolling window period from the set of rolling window periods, the distance of the residual mean from 0 by calculating Cohen's d.</li></ul></li><li id="ul0078-0015" num="0659">7. The apparatus of embodiment 1, further, comprising:</li><li id="ul0078-0016" num="0660">the processor-executable instructions structured as: <ul id="ul0085" list-style="none"><li id="ul0085-0001" num="0661">utilize big data framework, Spark, with Elastic Map Reduce (EMR) and EMR Notebook, to support processing and storage in a parallel and distributed way.</li></ul></li><li id="ul0078-0017" num="0662">8. The apparatus of embodiment 7, further, comprising:</li><li id="ul0078-0018" num="0663">the processor-executable instructions structured as: <ul id="ul0086" list-style="none"><li id="ul0086-0001" num="0664">utilize Spark to analyze computation tasks and optimize processing workflow prior to code execution.</li></ul></li><li id="ul0078-0019" num="0665">9. The apparatus of embodiment 8, further, comprising:</li><li id="ul0078-0020" num="0666">the processor-executable instructions structured as: <ul id="ul0087" list-style="none"><li id="ul0087-0001" num="0667">use EMR Notebooks along with EMR clusters to submit Spark jobs for parallel computing.</li></ul></li><li id="ul0078-0021" num="0668">10. The apparatus of embodiment 9, further, comprising:</li><li id="ul0078-0022" num="0669">the processor-executable instructions structured as: <ul id="ul0088" list-style="none"><li id="ul0088-0001" num="0670">execute EMR using a cloud computing infrastructure.</li></ul></li><li id="ul0078-0023" num="0671">11. The apparatus of embodiment 10, further, comprising:</li><li id="ul0078-0024" num="0672">EMR Notebook is structured to provide at least one of the following features: support for multiple programming languages, test and debug code interactively, monitor Spark activity from within a notebook, visualize large datasets and resume at broken steps, and detach and attach a notebook to different EMR clusters.</li><li id="ul0078-0025" num="0673">12. The apparatus of embodiment 7, further, comprising:</li><li id="ul0078-0026" num="0674">the processor-executable instructions structured as: <ul id="ul0089" list-style="none"><li id="ul0089-0001" num="0675">create an EMR cluster with a predefined bootstrap script including the dependencies utilized by a service;</li><li id="ul0089-0002" num="0676">execute the predefined bootstrap script on each worker node in a cluster script to have dependent libraries installed;</li><li id="ul0089-0003" num="0677">create an EMR Notebook with a pre-defined service Identity and Access Management (IAM) role and connect the EMR Notebook to the EMR cluster;</li><li id="ul0089-0004" num="0678">load input data into the EMR cluster and store among core nodes in a distributed way once the EMR cluster is in ready status;</li><li id="ul0089-0005" num="0679">group assets by the asset id and apply Spark mapper and reducer functions on each asset to conduct a series of transformations and reductions; and</li><li id="ul0089-0006" num="0680">save a trained model in binary format or predicted scores by the trained model into Postgres database after the series of transformations and reductions are conducted.</li></ul></li><li id="ul0078-0027" num="0681">13. The apparatus of embodiment 1, further, comprising:</li><li id="ul0078-0028" num="0682">the processor-executable instructions structured as: <ul id="ul0090" list-style="none"><li id="ul0090-0001" num="0683">provision an event-driven, self-service, and extensible big data and machine learning self-service computation engine using a collection of components implemented in a Workflow Declaration Language (WDL).</li></ul></li><li id="ul0078-0029" num="0684">14. The apparatus of embodiment 1, further, comprising:</li><li id="ul0078-0030" num="0685">the processor-executable instructions structured as: <ul id="ul0091" list-style="none"><li id="ul0091-0001" num="0686">declaratively define a desired state of big data and machine learning pipelines;</li><li id="ul0091-0002" num="0687">programmatically transform the desired state into a workflow;</li><li id="ul0091-0003" num="0688">generate workflow code associated with the workflow for resource provision, job submission, job scheduling, job monitoring and job dependency orchestration; and</li><li id="ul0091-0004" num="0689">inject the workflow code into a container for scheduling and execution.</li></ul></li><li id="ul0078-0031" num="0690">15. The apparatus of embodiment 1, further, comprising:</li><li id="ul0078-0032" num="0691">the processor-executable instructions structured as: <ul id="ul0092" list-style="none"><li id="ul0092-0001" num="0692">utilize a plurality of platform-executable jobs derived from big data and machine learning artifacts, structured to execute with desired or elastic capacity on a variety of platforms and services including at least one of: multi-node clusters, virtual servers, containers and lambda functions.</li></ul></li><li id="ul0078-0033" num="0693">16. The apparatus of embodiment 1, further, comprising:</li><li id="ul0078-0034" num="0694">the processor-executable instructions structured as: <ul id="ul0093" list-style="none"><li id="ul0093-0001" num="0695">utilize an event-driven architecture with loosely coupled event producers and consumers, integrated to: <ul id="ul0094" list-style="none"><li id="ul0094-0001" num="0696">fulfill the prescription of resource allocation;</li><li id="ul0094-0002" num="0697">generate workflow code to facilitate self-service;</li><li id="ul0094-0003" num="0698">provision vertical and horizontal scalability; and</li><li id="ul0094-0004" num="0699">support fault-tolerance.</li></ul></li></ul></li><li id="ul0078-0035" num="0700">17. The apparatus of embodiment 1, further, comprising:</li><li id="ul0078-0036" num="0701">the processor-executable instructions structured as: <ul id="ul0095" list-style="none"><li id="ul0095-0001" num="0702">utilize parallel on parallel hierarchy and flexible calculation dependencies, structured to facilitate multiple jobs to be concurrently distributed to multiple nodes with tasks in each job executed in parallel.</li></ul></li><li id="ul0078-0037" num="0703">18. The apparatus of embodiment 1, further, comprising:</li><li id="ul0078-0038" num="0704">heterogenous platforms consists of EMR, EC2, ECS and Lambda functions;</li><li id="ul0078-0039" num="0705">a set of supported languages: Scala, Java and Python.</li><li id="ul0078-0040" num="0706">19. The apparatus of embodiment 1, further, comprising:</li><li id="ul0078-0041" num="0707">generic roles and responsibilities defined as interfaces for functional implementation;</li><li id="ul0078-0042" num="0708">open source technologies adopted to ensure cloud provider agnosticism.</li><li id="ul0078-0043" num="0709">20. The apparatus of embodiment 1, further, comprising:</li><li id="ul0078-0044" num="0710">the processor-executable instructions structured as: <ul id="ul0096" list-style="none"><li id="ul0096-0001" num="0711">utilize network-optimized, memory-optimized or compute-optimized cloud instances.</li></ul></li><li id="ul0078-0045" num="0712">21. The apparatus of embodiment 1, further, comprising:</li><li id="ul0078-0046" num="0713">an optimization with cost leveraging: <ul id="ul0097" list-style="none"><li id="ul0097-0001" num="0714">inexpensive and commodity-grade virtual servers;</li><li id="ul0097-0002" num="0715">price-discount with Spot Instances or Reserved Instances.</li></ul></li><li id="ul0078-0047" num="0716">22. The apparatus of embodiment 1, further, comprising:</li><li id="ul0078-0048" num="0717">the processor-executable instructions structured as: <ul id="ul0098" list-style="none"><li id="ul0098-0001" num="0718">utilize a unified, distributed, parallel, generic computation engine supporting big data batch and streaming processing for financial data extraction, transformation, and load (ETL) and simulation.</li></ul></li></ul>

Simulating Equity Returns Under Different Market Scenarios Using a Set of Machine Learning and Cloud Computing Techniques

0000<ul id="ul0099" list-style="none"><li id="ul0099-0001" num="0719">1. A machine learning equity returns simulating apparatus, comprising:</li><li id="ul0099-0002" num="0720">a memory;</li><li id="ul0099-0003" num="0721">a component collection in the memory;</li><li id="ul0099-0004" num="0722">a processor disposed in communication with the memory and configured to issue a plurality of processor-executable instructions from the component collection, the processor-executable instructions structured as: <ul id="ul0100" list-style="none"><li id="ul0100-0001" num="0723">obtain, via at least one processor, equity's historical daily returns data sets, a set of rolling window period lengths, and data sets for the set of market factors' historical returns during the specified rolling window periods;</li><li id="ul0100-0002" num="0724">compute, via at least one processor, for each equity, the returns during each rolling window period from the set of rolling window periods, by aggregating the historical daily returns;</li><li id="ul0100-0003" num="0725">construct, via at least one processor, from a set of market factor pairs, a set of spread factors, by computing the difference in returns between each pair of market factors under simulated market scenarios, in order to create orthogonal features to mitigate the problem of multicollinearity;</li><li id="ul0100-0004" num="0726">update, via at least one processor, the set of market factors to include the set of spread factors;</li><li id="ul0100-0005" num="0727">evaluate, via at least one processor, for each equity, for each market factor in the updated set of market factors, the importance level of the market factor's impact on the equity, using XGBoost's feature importance measurement;</li><li id="ul0100-0006" num="0728">allow, via at least one processor, for each equity, from the updated set of market factors, domain experts to specify market factors to be later considered for utilization in the return-simulating model, based on its asset category (e.g., fixed income, US equity, international equity, etc.);</li><li id="ul0100-0007" num="0729">select, via at least one processor, for each equity, from the entire or domain-expert-specified set of market factors, the top contributing market factors to be later utilized in the return-simulating model, using a customized forward selection algorithm that maximizes regression models adjusted R², in order to enhance model performance and alleviate the issue of multicollinearity;</li><li id="ul0100-0008" num="0730">learn, via at least one processor, for each equity, for each rolling window period from the set of rolling window periods, its relationships with the set of selected market factors from their historical returns using ridge regression which regularizes regression coefficients and mitigates the problem of multicollinearity;</li><li id="ul0100-0009" num="0731">simulate, via at least one processor, for each equity, for each rolling window period from the set of rolling window periods, its returns under simulated market scenarios using XGBoost regression with the set of selected market factors and company specific financial factors;</li><li id="ul0100-0010" num="0732">calibrate, via at least one processor, for each equity, for each rolling window period from the set of rolling window periods, the returns to forward-looking capital market assumptions;</li><li id="ul0100-0011" num="0733">visualize real-time, via at least one processor, for each equity, or portfolio of equities, for each rolling window period from the set of rolling window periods, its simulated returns distributions under user-specified market scenarios (e.g., business cycle assumption, rising VIX scenario, etc.); and</li><li id="ul0100-0012" num="0734">illustrate, via at least one processor, for each equity, for each rolling window period from the set of rolling window periods, its exposure to selected market factor based on their historical returns.</li></ul></li><li id="ul0099-0005" num="0735">2. A machine learning equity returns model feature engineering apparatus, comprising:</li><li id="ul0099-0006" num="0736">a memory;</li><li id="ul0099-0007" num="0737">a component collection in the memory;</li><li id="ul0099-0008" num="0738">a processor disposed in communication with the memory and configured to issue a plurality of processor-executable instructions from the component collection, the processor-executable instructions structured as: <ul id="ul0101" list-style="none"><li id="ul0101-0001" num="0739">obtain, via at least one processor, equity's historical conditional betas data sets, a set of rolling window period lengths, data sets for the set of market factors' historical returns during the specified rolling window periods, and data sets for the set of company specific financials factors' historical values during the specified rolling window periods;</li><li id="ul0101-0002" num="0740">compute, via at least one processor, for each equity, during each rolling window period from the set of rolling window periods, the set of features contributing to a positive gain in feature importance ranking, by running nonparametric Gradient Boosting tree regression model; and</li><li id="ul0101-0003" num="0741">further compute, via at least one processor, for each equity, during each rolling window period from the set of rolling window periods, the smaller set of features contributing to a positive gain in adjusted R square, by running parametric regression model, in order to enhance model performance and alleviate the issue of multicollinearity.</li></ul></li><li id="ul0099-0009" num="0742">3. A residual validation workflow apparatus, comprising:</li><li id="ul0099-0010" num="0743">a memory;</li><li id="ul0099-0011" num="0744">a component collection in the memory;</li><li id="ul0099-0012" num="0745">a processor disposed in communication with the memory and configured to issue a plurality of processor-executable instructions from the component collection, the processor-executable instructions structured as: <ul id="ul0102" list-style="none"><li id="ul0102-0001" num="0746">obtain, via at least one processor, equity's conditional beta model training and test data sets, a set of rolling window period lengths, and data sets for predicted conditional beta through trained model on the same processor;</li><li id="ul0102-0002" num="0747">compute, via at least one processor, for each equity, the residual correlation between the predicted beta and residuals of prediction, the residual normal p value, the residual effective size, the residual Mann Whitney U value, and the residual standard deviation; and</li><li id="ul0102-0003" num="0748">validate, via at least one processor, from a set of residual analysis matrix, that beta residuals from models are unbiased, that beta residuals from models are substantively close to zero.</li></ul></li><li id="ul0099-0013" num="0749">4. A machine learning equity idiosyncratic risk model apparatus, comprising:</li><li id="ul0099-0014" num="0750">a memory;</li><li id="ul0099-0015" num="0751">a component collection in the memory;</li><li id="ul0099-0016" num="0752">a processor disposed in communication with the memory and configured to issue a plurality of processor-executable instructions from the component collection, the processor-executable instructions structured as: <ul id="ul0103" list-style="none"><li id="ul0103-0001" num="0753">obtain, via at least one processor, equity's historical idiosyncratic risk data sets, a set of rolling window period lengths, data sets for the set of market factors' historical returns during the specified rolling window periods, and data sets for the set of company specific financials factors' historical values during the specified rolling window periods;</li><li id="ul0103-0002" num="0754">compute, via at least one processor, for each equity, during each rolling window period from the set of rolling window periods, with the set of features contributing to a positive gain in feature importance ranking and contributing to a positive gain in adjusted R square, the weighted sum squared Euclidean distance between each simulated market scenario and each historical scenario; and</li><li id="ul0103-0003" num="0755">select, via at least one processor, for each equity, during each rolling window period from the set of rolling window periods, the closest historical scenario to simulated market scenarios, and assign the stored idiosyncratic risk of this historical scenario to this simulated market scenario.</li></ul></li><li id="ul0099-0017" num="0756">5. The apparatus of embodiment 1, further, comprising:</li><li id="ul0099-0018" num="0757">Spark analyzes computation tasks and optimize the workflow of the data processing before actually executing the code, which makes it outperforms Hadoop in terms of performance with Directed Acyclic Graph (DAG) optimizations and in memory processing.</li><li id="ul0099-0019" num="0758">6. The apparatus of embodiment 5, further, comprising: <ul id="ul0104" list-style="none"><li id="ul0104-0001" num="0759">use EMR Notebooks along with EMR clusters to submit Spark jobs for parallel computing to improve the development efficiency.</li></ul></li><li id="ul0099-0020" num="0760">7. The apparatus of embodiment 6, further, comprising:</li><li id="ul0099-0021" num="0761">EMR to make full usage of compute power offered by the cloud provider and save compute costs, since the EMR runtime for Spark can be over 3 times faster than standard Spark.</li><li id="ul0099-0022" num="0762">8. The apparatus of embodiment 7, further, comprising:</li><li id="ul0099-0023" num="0763">EMR Notebook provides following functionalities and characteristics:</li><li id="ul0099-0024" num="0764">support multiple programming languages;</li><li id="ul0099-0025" num="0765">test and debug code interactively;</li><li id="ul0099-0026" num="0766">monitor Spark activity from within the notebook;</li><li id="ul0099-0027" num="0767">visualize large datasets and resuming at broken steps; and</li><li id="ul0099-0028" num="0768">detach and attach a notebook to different EMR clusters easily.</li><li id="ul0099-0029" num="0769">9. The apparatus of embodiment 8, further, comprising:</li><li id="ul0099-0030" num="0770">the workflow of parallel computing of a single task of asset simulation with EMR Notebook comprising: <ul id="ul0105" list-style="none"><li id="ul0105-0001" num="0771">create an EMR cluster with a predefined bootstrap script including all the dependencies required by a service;</li><li id="ul0105-0002" num="0772">execute the bootstrap script on each worker node in the cluster script to have dependent libraries installed;</li><li id="ul0105-0003" num="0773">create an EMR Notebook with a pre-defined service IAM role and connect it to the EMR cluster;</li><li id="ul0105-0004" num="0774">load input data into EMR cluster and store among the core nodes in a distributed way once the EMR cluster is in ready status;</li><li id="ul0105-0005" num="0775">group assets by the asset id and apply Spark mapper and reducer functions on each asset to conduct a series of transformations and reductions; and</li><li id="ul0105-0006" num="0776">save the eventual results, such as trained model in the format of binary or predicted scores by the model into Postgres database after the transformations are finished.</li></ul></li><li id="ul0099-0031" num="0777">10. The apparatus of embodiment 1, further, comprising:</li><li id="ul0099-0032" num="0778">A big data and machine learning self-service computation platform, comprising:</li><li id="ul0099-0033" num="0779">a Workflow Declaration Language (WDL);</li><li id="ul0099-0034" num="0780">an implementation of the WDL;</li><li id="ul0099-0035" num="0781">a collection of components in the WDL structured as: <ul id="ul0106" list-style="none"><li id="ul0106-0001" num="0782">provision an event-driven, self-service, and extensible computation engine.</li></ul></li><li id="ul0099-0036" num="0783">11. The apparatus of embodiment 1, further, comprising:</li><li id="ul0099-0037" num="0784">the executable instructions structured as: <ul id="ul0107" list-style="none"><li id="ul0107-0001" num="0785">declaratively define the desired state of big data and machine learning pipelines;</li><li id="ul0107-0002" num="0786">programmatically transform the desired state into workflow;</li><li id="ul0107-0003" num="0787">automatically generate workflow code for resource provision, job submission, job scheduling, job monitoring and Job dependency orchestration; and</li><li id="ul0107-0004" num="0788">automatically inject the workflow into a container for scheduling and execution.</li></ul></li><li id="ul0099-0038" num="0789">12. The apparatus of embodiment 1, further, comprising:</li><li id="ul0099-0039" num="0790">a plurality of platform-executable jobs derived from big data and machine learning artifacts, structured as: <ul id="ul0108" list-style="none"><li id="ul0108-0001" num="0791">execute on a variety of platforms and services with desired or elastic capacity: multi-node clusters, virtual servers, containers and lambda functions.</li></ul></li><li id="ul0099-0040" num="0792">13. The apparatus of embodiment 1, further, comprising:</li><li id="ul0099-0041" num="0793">an event-driven architecture with loosely coupled event producers and consumers, integrated to: <ul id="ul0109" list-style="none"><li id="ul0109-0001" num="0794">fulfil the prescription of resource allocation;</li><li id="ul0109-0002" num="0795">generate workflow code to facilitate self-service;</li><li id="ul0109-0003" num="0796">provision vertical and horizontal scalability; and</li><li id="ul0109-0004" num="0797">support fault-tolerance.</li></ul></li><li id="ul0099-0042" num="0798">14. The apparatus of embodiment 1, further, comprising:</li><li id="ul0099-0043" num="0799">parallel on parallel hierarchy and flexible calculation dependencies, structured as: <ul id="ul0110" list-style="none"><li id="ul0110-0001" num="0800">enable multiple jobs to be concurrently distributed to multiple nodes with tasks in each job executed in parallel.</li></ul></li><li id="ul0099-0044" num="0801">15. The apparatus of embodiment 1, further, comprising:</li><li id="ul0099-0045" num="0802">heterogenous platforms consists of EMR, EC2, ECS and Lambda functions;</li><li id="ul0099-0046" num="0803">a set of supported languages: Scala, Java and Python;</li><li id="ul0099-0047" num="0804">16. The apparatus of embodiment 1, further, comprising:</li><li id="ul0099-0048" num="0805">generic roles and responsibilities defined as interfaces for functional implementation;</li><li id="ul0099-0049" num="0806">open source technologies adopted to ensure cloud provider agnosticism.</li><li id="ul0099-0050" num="0807">17. The apparatus of embodiment 1, further, comprising:</li><li id="ul0099-0051" num="0808">an optimization with performance by using network-optimized, memory-optimized and/or compute-optimized cloud instances based on the nature of the computation.</li><li id="ul0099-0052" num="0809">18. The apparatus of embodiment 1, further, comprising:</li><li id="ul0099-0053" num="0810">an optimization with cost leveraging: <ul id="ul0111" list-style="none"><li id="ul0111-0001" num="0811">inexpensive and commodity-grade virtual servers;</li><li id="ul0111-0002" num="0812">price-discount with Spot Instances or Reserved Instances.</li></ul></li><li id="ul0099-0054" num="0813">19. The apparatus of embodiment 1, further, comprising:</li><li id="ul0099-0055" num="0814">a unified, distributed, parallel, generic computation engine supporting: <ul id="ul0112" list-style="none"><li id="ul0112-0001" num="0815">big data batch and streaming processing for financial data ETL and simulation;</li><li id="ul0112-0002" num="0816">machine learning training and scoring for fixed income, equity and mutual fund and ETF.</li></ul></li><li id="ul0099-0056" num="0817">20. The apparatus of embodiment 1, further, comprising:</li><li id="ul0099-0057" num="0818">the processor-executable instructions structured as: <ul id="ul0113" list-style="none"><li id="ul0113-0001" num="0819">apply big data framework, Spark, with EMR and EMR Notebook, to support the data process and storage in a parallel and distributed way.</li></ul></li></ul>

Optimized Portfolio Generation Using Simulated or Realized Returns with Loss Tolerance or Return Volatility Controls, Generation of Mean-CVaR and Mean-Variance Frontiers with Parallel Computing

0000<ul id="ul0114" list-style="none"><li id="ul0114-0001" num="0820">1. A Tail Risk Optimizer risk tool, comprising: <ul id="ul0115" list-style="none"><li id="ul0115-0001" num="0821">1. an optimization finding the optimal portfolio weights set that reaches max return along with conditional Value at Risk constraints and self-defined asset max allocation weights. The optimization process is structured as:</li><li id="ul0115-0002" num="0822">2. define, via users' loss tolerance, a CVaR threshold percentage that is allowed within the portfolio and self-defined max allocation for each asset in the portfolio, and;</li><li id="ul0115-0003" num="0823">3. obtain, via at least one processor, assets' simulated returns data sets, a set of return data of each asset with different market scenarios, to:</li><li id="ul0115-0004" num="0824">4. convert, via CVaR linear relaxation, the convex CVaR calculation into a linear system to accelerate the optimizer; with an introduction of some auxiliary variable to discretize the integral in general CVaR computation process;</li><li id="ul0115-0005" num="0825">5. optimize; via mixed integer programming techniques; the portfolio expected return with specified asset max allocation, CVaR threshold and allowed volume of cash holdings; acquire, via parallel computation, a proposed set of portfolio weights and its expected return/volatility/drawdown; taking advantages of compute power provided by cloud platform and applies AWS Elastic Container Service (ECS) which is a fully managed container orchestration service to handle requests in a parallel way. Multiple user requests are loaded into different containers that are hosted on a cluster of EC2 machines. Within a single request, the computation process of CVAR is distributed among different CPU cores in each container using multiprocessing mechanism. By using parallel computing techniques, ECS and multiprocessing, the service performance is significantly improved.</li><li id="ul0115-0006" num="0826">6. visualize, via CVaR-Mean frontier plot consisting of hundreds of optimal portfolio points with current constraints but different CVaR threshold, portfolio return versus portfolio CVaR; the relative position between the current optimal portfolio and initial portfolio. Allowing changes of scenarios, business cycles or optimization types, the CVaR-Mean frontier to change accordingly and the capacity of comparing optimal portfolios under different scenarios and methodologies.</li></ul></li><li id="ul0114-0002" num="0827">2. A Mean Variance Optimizer risk tool, comprising: <ul id="ul0116" list-style="none"><li id="ul0116-0001" num="0828">1. an optimization finding the best balance between expected return and portfolio risk according to a user specified risk tolerance level and self-defined asset max allocation weights. The optimization process is structured as:</li><li id="ul0116-0002" num="0829">2. define, via users' preference, a risk tolerance level ranging from 0 to 10 as risk averse situation to risk seeking situation, corresponding to conservative investors to aggressive investors and;</li><li id="ul0116-0003" num="0830">3. obtain, via at least one processor, assets' simulated returns data sets, a set of return data of each asset with different market scenarios, to:</li><li id="ul0116-0004" num="0831">4. estimate, via Ledoit-Wolf covariance matrix estimation method which corrects both bias and variance of sample covariance matrix or; historical-based covariance matrix estimation method with addition of a small number on the diagonal to decorrelate asset behavior to capture accurate and robust portfolio risk;</li><li id="ul0116-0005" num="0832">5. optimize; via objective function of maximizing sum of the portfolio return and a risk penalty with coefficient as risk tolerance parameter; along with the constraints of specified asset max allocation as well as the integrity of portfolio weights summation; acquire, via parallel computation, a proposed set of portfolio weights and its expected return/volatility/drawdown; taking advantages of compute power provided by cloud platform and applies AWS Elastic Container Service (ECS) which is a fully managed container orchestration service to handle requests in a parallel way. Multiple user requests are loaded into different containers that are hosted on a cluster of EC2 machines. Within a single request, the computation process of CVAR is distributed among different CPU cores in each container using multiprocessing mechanism. By using parallel computing techniques, ECS and multiprocessing, the service performance is significantly improved.</li><li id="ul0116-0006" num="0833">6. visualize, via efficient frontier (Volatility-Mean) plot consisting of around 1700 optimal portfolio points with current constraints but different risk tolerance level, portfolio return versus portfolio risk; the relative position between the current optimal portfolio and initial portfolio. Allowing changes of scenarios, business cycles or optimization types, the efficient frontier to change accordingly and the capacity of comparing optimal portfolios under different scenarios and methodologies.</li></ul></li></ul>

Constructing Predefined Scenarios (GUI) Using Simulated Market Scenarios and Scenario-Based Risk Reporting Using Multiple User-Defined Scenarios

0000<ul id="ul0117" list-style="none"><li id="ul0117-0001" num="0834">1. A computer program or application comprising a volatile or non-volatile computer usable medium having executable code to execute a process for generating scenario-based risk reporting for multiple user-specified scenarios, the process comprising:</li><li id="ul0117-0002" num="0835">obtain, on all available processors, for all securities, load asset simulation data in temporary storage or memory based on time-horizon selected by the user, input passed to the process as a data structure; input data structure includes user-specified scenarios; generate asset simulation data if not available; load call and put schedule in temporary storage or memory to be used by alternate asset simulation process;</li><li id="ul0117-0003" num="0836">simulate, as alternate asset simulation process, on all available processors, for all securities, calculate the dot product of factor exposure for selected securities and factor simulations; adjust simulated returns for assets based on call and put schedule;</li><li id="ul0117-0004" num="0837">generate, on all available processors, for all available user-defined scenarios, find markets matching user provided criteria; apply multiple criteria as provided in user input; store list of markets in a map data structure in temporary storage or memory;</li><li id="ul0117-0005" num="0838">calculate, on all available processors, for all available user-defined scenarios from the map, get market returns based on markets in the map entry; calculate weighted average market returns using asset simulation returns and security weights; store market returns to the map;</li><li id="ul0117-0006" num="0839">compute, as main process, on all available processors, for all available user-defined scenarios from the map, use the market returns stored in the map to calculate tail-risk and other risk-based analytics; and</li><li id="ul0117-0007" num="0840">visualize real-time, via at least one processor, for each portfolio, for each rolling window period from the set of rolling window periods, its simulated returns distributions under user-specified market scenarios or business cycles (e.g., rising interest rates, recession, etc.).</li></ul>

Fixed Income Securities Returns Simulation and Portfolio Risk Aggregation Using Oracle RDS or Map Reduce Cloud Computing Technologies

0000<ul id="ul0118" list-style="none"><li id="ul0118-0001" num="0841">1. A database-implemented procedure for multi-risk factor risk engine method executed by one or more processors, the method comprising:</li><li id="ul0118-0002" num="0842">obtain, a list of unique securities for which a main operation needs to be executed based on user provided inputs for data filtering;</li><li id="ul0118-0003" num="0843">filter, factor exposures data based on list of unique securities and store in temporary storage or memory; Use Oracle RDS Global Temporary Tables (GTT) to run batch in multiple sessions; further filter, factor simulation data based on unique factors available from factor exposure data and store in temporary storage or memory; if factor exposure data not available, calculate factor exposure data as alternate operation for current pricing date;</li><li id="ul0118-0004" num="0844">process, the alternate operation, on all available processors, calculate spread ratio for all securities using dimension reduction; store calculated factor exposure in local storage or memory; Use Global Temporary Tables where needed for temporary storage;</li><li id="ul0118-0005" num="0845">process, the main operation, all available unique securities in small chunks or batches, for each batch;</li><li id="ul0118-0006" num="0846">retrieve, from temporary storage or memory, the necessary factor simulation and factor exposure data relevant to the unique securities within the batch;</li><li id="ul0118-0007" num="0847">execute, for all available processors, in parallel, for each security within the batch, the sum product of factor exposure and factor simulations for each security and store result asset simulation data in temporary storage or memory; Use combination of Oracle's Parallel Queries and Global Temporary Tables to parallelize computations;</li><li id="ul0118-0008" num="0848">calibrate, for all available processors, in parallel, the asset simulated returns for each security, based on call and put schedule data available for each security;</li><li id="ul0118-0009" num="0849">transpose, from temporary storage or memory, retrieve the asset simulation data for each security within the batch and transpose data from individual records to a list-based data structure and store results to permanent storage in database; Use of Oracle's DDL commands for faster cleanup of Global Temporary Tables (GTT).</li><li id="ul0118-0010" num="0850">Adding the carry return of fixed income instruments based on estimated maturity date. Such that if the security matures within the simulated investment time horizon, the yield to the estimated maturity date is used to represent the carry return.</li><li id="ul0118-0011" num="0851">Adjusting the call and put schedules by not allowing the simulated price returns to go beyond the call or put prices if the call and put schedules fall in the simulation time horizon.</li><li id="ul0118-0012" num="0852">Adjusting for default probabilities by ensuring the simulated returns represent loss given default given the conditional default flag for the instrument under the different simulated markets.</li><li id="ul0118-0013" num="0853">Adjusting for conditional spread beta in the price return calculations given the conditional spread beta for the instrument under the different simulated markets.</li><li id="ul0118-0014" num="0854">Adjusting for convexity of the fixed income instruments in the simulating of the price returns.</li><li id="ul0118-0015" num="0855">2. The apparatus of embodiment 1, further, comprising:</li><li id="ul0118-0016" num="0856">parallel on parallel hierarchy and flexible calculation dependencies, structured as: <ul id="ul0119" list-style="none"><li id="ul0119-0001" num="0857">enable multiple jobs to be concurrently scheduled and executed on Oracle RDS with tasks in each job executed in parallel.</li></ul></li><li id="ul0118-0017" num="0858">3. The apparatus of embodiment 1, further, comprising:</li><li id="ul0118-0018" num="0859">ability to compute simulated returns for all time-horizons simultaneously, structured as: <ul id="ul0120" list-style="none"><li id="ul0120-0001" num="0860">store calculated simulated return data as separate columns and stored in temporary cache or storage;</li><li id="ul0120-0002" num="0861">transpose calculated simulated returns using PIVOT and UNPIVOT Oracle commands to provide capability to compute simulated returns simultaneously and storing data back to the database in parallel.</li></ul></li><li id="ul0118-0019" num="0862">4. The apparatus of embodiment 1, further, comprising:</li><li id="ul0118-0020" num="0863">Unique design to store simulated returns and market scenario id as a single number. An array of such numbers is stored in storage medium and transported between storage medium and API/UI layer. The unique design ensured data compression, no need to encode/decode compressed data and parallel portfolio risk aggregation for multiple market scenarios, multiple time horizons and multiple portfolios concurrently. <br /> (e.g. <simulated_return>.<market_id> a single number: “−142.0153” where −142 is the simulated return in bps and 153 is the market id. This single dimensional array is a unique data format to support aggregate portfolio simulated returns in parallel. This data format eliminates the complexity to maintain mapping of the returns to market scenarios. At the API layer, in processing this single dimensional array in parallel, there is no need for compression/decompression logic.) </li><li id="ul0118-0021" num="0864">5. The apparatus of embodiment 1, further, comprising:</li><li id="ul0118-0022" num="0865">heterogeneous platforms comprising: Oracle RDS on Cloud, Job Scheduler and Lambda functions;</li><li id="ul0118-0023" num="0866">a set of supported languages: PL-SQL, Java and Python.</li><li id="ul0118-0024" num="0867">6. The apparatus of embodiment 1, further, comprising:</li><li id="ul0118-0025" num="0868">an optimization with performance by using memory-optimized and/or compute-optimized database instances based on the nature of the computation.</li><li id="ul0118-0026" num="0869">7. The apparatus of embodiment 1, further, comprising:</li><li id="ul0118-0027" num="0870">Apply big data framework, Spark, with EMR and EMR Notebook, to support the data process and storage in a parallel and distributed way.</li><li id="ul0118-0028" num="0871">8. The apparatus of embodiment 7, further, comprising:</li><li id="ul0118-0029" num="0872">Spark analyzes computation tasks and optimize the workflow of the data processing before actually executing the code, which makes it outperforms Hadoop in terms of performance with Directed Acyclic Graph (DAG) optimizations and in memory processing.</li><li id="ul0118-0030" num="0873">9. The apparatus of embodiment 8, further, comprising: <ul id="ul0121" list-style="none"><li id="ul0121-0001" num="0874">use EMR Notebooks along with EMR clusters to submit Spark jobs for parallel computing to improve the development efficiency.</li></ul></li><li id="ul0118-0031" num="0875">10. The apparatus of embodiment 9, further, comprising:</li><li id="ul0118-0032" num="0876">EMR to make full usage of compute power offered by the cloud provider and save compute costs, since the EMR runtime for Spark can be over 3 times faster than standard Spark.</li><li id="ul0118-0033" num="0877">11. The apparatus of embodiment 10, further, comprising:</li><li id="ul0118-0034" num="0878">EMR Notebook provides following functionalities and characteristics: support multiple programming languages; test and debug code interactively; monitor Spark activity from within the notebook; visualize large datasets and resuming at broken steps; and detach and attach a notebook to different EMR clusters easily.</li><li id="ul0118-0035" num="0879">12. The apparatus of embodiment 11, further, comprising:</li><li id="ul0118-0036" num="0880">the workflow of parallel computing of a single task of asset simulation with EMR Notebook comprising: <ul id="ul0122" list-style="none"><li id="ul0122-0001" num="0881">create an EMR cluster with a predefined bootstrap script including all the dependencies required by a service;</li><li id="ul0122-0002" num="0882">execute the bootstrap script on each worker node in the cluster script to have dependent libraries installed;</li><li id="ul0122-0003" num="0883">create an EMR Notebook with a pre-defined service IAM role and connect it to the EMR cluster;</li><li id="ul0122-0004" num="0884">load input data into EMR cluster and store among the core nodes in a distributed way once the EMR cluster is in ready status;</li><li id="ul0122-0005" num="0885">group assets by the asset id and apply Spark mapper and reducer functions on each asset to conduct a series of transformations and reductions;</li><li id="ul0122-0006" num="0886">save the eventual results, such as trained model in the format of binary or predicted scores by the model into Postgres database after the transformations are finished; and</li><li id="ul0122-0007" num="0887">calculate, for all available processors, in parallel, for each security within the batch, sort available asset sims returns in increasing order, take average of top five percent data and store result to permanent storage in database; Use Parallel DML to parallelize inserting records into the database.</li></ul></li></ul>

Tail-Risk Adjusted Bond Ladder Construction

0000<ul id="ul0123" list-style="none"><li id="ul0123-0001" num="0888">1. A computer program or application comprising a volatile or non-volatile computer usable medium having executable code to execute a process for constructing a bond ladder based on risk adjusted yield, the process comprising:</li><li id="ul0123-0002" num="0889">obtain, a list of available bond offerings available for trading from various sources, based on filter criteria provided by the user, the input provided in a data structure available to the program;</li><li id="ul0123-0003" num="0890">retrieve, all analytics data related to available bonds, including default probability, conditional value at risk (CVAR), yield, price, available quantity to trade, etc.;</li><li id="ul0123-0004" num="0891">calculate, on all available processors, mean and standard deviation, for all bonds with default probability; calculate same for all bonds with CVAR data; store computed mean and standard deviation in temporary storage or memory;</li><li id="ul0123-0005" num="0892">calculate, on all available processors, for all available bonds, the z-score based on default probability of the bond, mean and standard deviation of default probabilities of all bonds; For bonds with no default probability, calculate z-score based on CVAR of the bond, mean and standard deviation of CVAR for all bonds; adjusted yield for the bond based on the computed z-score;</li><li id="ul0123-0006" num="0893">sort, all available bonds based on adjusted yield, rating and available quantity; group data in rungs based on maturity dates;</li><li id="ul0123-0007" num="0894">process, as main operation, on all available processors, calculate allocated value for all bonds within the rung; per bond based on minimum increment, minimum denomination, diversification and minimum balance remaining constraints; store residual cash not allocated per rung into memory;</li><li id="ul0123-0008" num="0895">compute, on all available processors, for all rungs, calculate weighted average yield per rung; find rung with highest overall yield;</li><li id="ul0123-0009" num="0896">process, as final operation, on all available processors, calculate allocated value for all bonds within the maximum yielding rung, calculate allocated value per bond based on minimum increment, minimum denomination, diversification and maximum balance remaining constraints;</li><li id="ul0123-0010" num="0897">visualize real-time, via at least one processor, for each portfolio, display constructed bond ladder based on rungs as maturity year; display portfolio level risk analytics;</li><li id="ul0123-0011" num="0898">2. The apparatus of embodiment 1, further, comprising:</li><li id="ul0123-0012" num="0899">the instructions to calculate in parallel, mean and standard deviation based on default probability and CVaR for each rung comprising instructions to: <ul id="ul0124" list-style="none"><li id="ul0124-0001" num="0900">generate, on all available processors; a map of all available securities available in each rung that has a valid default probability or CVaR; and</li><li id="ul0124-0002" num="0901">generate and store in parallel; on all available processors; using temporary memory, a final computed values of mean and standard deviation by rung number, from all available securities in the map.</li></ul></li><li id="ul0123-0013" num="0902">3. The apparatus of embodiment 1, further, comprising:</li><li id="ul0123-0014" num="0903">the instructions to calculate in parallel, the default probability of securities based on maturity year for which the default probabilities are not available comprising of instructions to: <ul id="ul0125" list-style="none"><li id="ul0125-0001" num="0904">determine, on all available processors; for all securities the default probability of securities with missing data; using default probabilities for available years; and</li><li id="ul0125-0002" num="0905">calculate, on all available processors, the default probabilities using average of the prior and next year's default probability.</li></ul></li><li id="ul0123-0015" num="0906">4. The apparatus of embodiment 1, further, comprising:</li><li id="ul0123-0016" num="0907">the instructions to calculate the highest yielding run based on weighted average calculations; structured as: <ul id="ul0126" list-style="none"><li id="ul0126-0001" num="0908">determine, on all available processors; for all available rungs, securities that have quantities allocated; create a map for each rung; and</li><li id="ul0126-0002" num="0909">calculate, on all available processors, the weighted average yield for each rung using the yield of each security and weight of the security based on market value for each rung.</li></ul></li><li id="ul0123-0017" num="0910">5. The apparatus of embodiment 1, further, comprising:</li><li id="ul0123-0018" num="0911">the instructions to return additional securities available for the user; for each rung based on highest available yield for each security: <ul id="ul0127" list-style="none"><li id="ul0127-0001" num="0912">determine, on all available processors; for all available rungs; sort and list additional bonds for all securities.</li></ul></li><li id="ul0123-0019" num="0913">6. The apparatus of embodiment 1, further, comprising:</li><li id="ul0123-0020" num="0914">parallel on parallel hierarchy and flexible calculation dependencies, structured as: <ul id="ul0128" list-style="none"><li id="ul0128-0001" num="0915">facilitate bond ladder construction to be executed in parallel for each rung based on maturity date for the securities. The allocation logic executes in parallel for each rung.</li></ul></li><li id="ul0123-0021" num="0916">7. The apparatus of embodiment 1, further, comprising:</li><li id="ul0123-0022" num="0917">heterogenous platforms consists of ECS, Parallel Streams and Java Web Caching;</li><li id="ul0123-0023" num="0918">a set of supported languages: Docker scripts, Java.</li><li id="ul0123-0024" num="0919">8. The apparatus of embodiment 1, further, comprising:</li><li id="ul0123-0025" num="0920">an optimization with performance by using network-optimized, memory-optimized and/or compute-optimized cloud instances based on the nature of the computation.</li></ul>

Additional Embodiments

0000<ul id="ul0129" list-style="none"><li id="ul0129-0001" num="0921">101. A machine learning portfolio generating apparatus, comprising:</li><li id="ul0129-0002" num="0922">a memory;</li><li id="ul0129-0003" num="0923">a component collection in the memory;</li><li id="ul0129-0004" num="0924">a processor disposed in communication with the memory and configured to issue a plurality of processor-executable instructions from the component collection, the processor-executable instructions structured as: <ul id="ul0130" list-style="none"><li id="ul0130-0001" num="0925">obtain, via at least one processor, a portfolio construction request datastructure, the portfolio construction request datastructure structured to include a set of optimization parameters including a universe of securities, a time period length, a conditional value at risk portion, a conditional value at risk threshold, a portfolio value amount;</li><li id="ul0130-0002" num="0926">determine, via at least one processor, a set of simulated market scenarios associated with the time period length, the set of simulated market scenarios generated using a set of deep learning neural networks, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values;</li><li id="ul0130-0003" num="0927">retrieve, via at least one processor, a set of expected returns for securities in the universe of securities for the set of simulated market scenarios, each expected return in the set of expected returns configured as calculated for a security during a simulated market scenario using: <ul id="ul0131" list-style="none"><li id="ul0131-0001" num="0928">the respective security's conditional Beta during the respective simulated market scenario, determined using a set of decision tree ensembles, trained to estimate conditional Beta of the respective security, based on a first subset of the set of simulated market factor values, and</li><li id="ul0131-0002" num="0929">the respective security's conditional default probability during the respective simulated market scenario, determined using a set of decision tree ensembles, trained to estimate conditional default probability of the respective security, based on a second subset of the set of simulated market factor values;</li></ul></li><li id="ul0130-0004" num="0930">optimize, via at least one processor, portfolio weights of securities in the universe of securities in accordance with the conditional value at risk portion, the conditional value at risk threshold, and the portfolio value amount, using the set of expected returns, to generate a set of tradeable transactions that maximize expected portfolio return of an optimized portfolio; and</li><li id="ul0130-0005" num="0931">execute, via at least one processor, the set of tradeable transactions to generate the optimized portfolio.</li></ul></li><li id="ul0129-0005" num="0932">102. The apparatus of embodiment 101, further, comprising:</li><li id="ul0129-0006" num="0933">the instructions to generate the set of simulated market scenarios using the set of deep learning neural networks are structured to comprise instructions to: <ul id="ul0132" list-style="none"><li id="ul0132-0001" num="0934">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0132-0002" num="0935">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0132-0003" num="0936">train, via at least one processor, for each time period bucket from the set of time period buckets, a deep learning neural network, from the set of deep learning neural networks, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0132-0004" num="0937">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained deep learning neural network associated with the respective time period bucket; and</li><li id="ul0132-0005" num="0938">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained deep learning neural network associated with the respective time period bucket.</li></ul></li><li id="ul0129-0007" num="0939">103. The apparatus of embodiment 102, further, comprising:</li><li id="ul0129-0008" num="0940">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0133" list-style="none"><li id="ul0133-0001" num="0941">determine, via at least one processor, a historical data set, a rolling window period length, and a set of market factors;</li><li id="ul0133-0002" num="0942">determine, via at least one processor, a set of rolling window periods using the historical data set and the rolling window period length; and</li><li id="ul0133-0003" num="0943">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0134" list-style="none"><li id="ul0134-0001" num="0944">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0009" num="0945">104. The apparatus of embodiment 103, further, comprising:</li><li id="ul0129-0010" num="0946">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0135" list-style="none"><li id="ul0135-0001" num="0947">determine, via at least one processor, the delta between values of the market factor at a beginning time point and an ending time point of the rolling window period.</li></ul></li><li id="ul0129-0011" num="0948">105. The apparatus of embodiment 104, further, comprising:</li><li id="ul0129-0012" num="0949">the processor-executable instructions structured as: <ul id="ul0136" list-style="none"><li id="ul0136-0001" num="0950">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0136-0002" num="0951">impute, via at least one processor, the unavailable historical data for the time point using a machine learning method.</li></ul></li><li id="ul0129-0013" num="0952">106. The apparatus of embodiment 103, further, comprising:</li><li id="ul0129-0014" num="0953">the rolling window period length is structured to be equal to the time period length.</li><li id="ul0129-0015" num="0954">107. The apparatus of embodiment 102, further, comprising:</li><li id="ul0129-0016" num="0955">the set of time period buckets is structured to have an equal fixed length for each time period bucket.</li><li id="ul0129-0017" num="0956">108. The apparatus of embodiment 102, further, comprising:</li><li id="ul0129-0018" num="0957">the set of time period buckets is structured to have a variable length for each time period bucket, the variable length for each time period bucket determined by judging the overall goodness of fit between the set of simulated market scenarios and the set of historical market scenarios.</li><li id="ul0129-0019" num="0958">109. The apparatus of embodiment 102, further, comprising:</li><li id="ul0129-0020" num="0959">the instructions to train a deep learning neural network for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0137" list-style="none"><li id="ul0137-0001" num="0960">select, via at least one processor, a historical market scenario from the associated subset of historical market scenarios; and</li><li id="ul0137-0002" num="0961">train, via at least one processor, the deep learning neural network for the time period bucket on the selected historical market scenario using a variational autoencoder.</li></ul></li><li id="ul0129-0021" num="0962">110. The apparatus of embodiment 109, further, comprising:</li><li id="ul0129-0022" num="0963">the deep learning neural network for the time period bucket is trained to generate a set of Gaussian mixture latent variables.</li><li id="ul0129-0023" num="0964">111. The apparatus of embodiment 110, further, comprising:</li><li id="ul0129-0024" num="0965">the instructions to generate simulated market scenarios for the time period bucket, using the trained deep learning neural network associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0138" list-style="none"><li id="ul0138-0001" num="0966">generate, via at least one processor, a set of random values for the set of Gaussian mixture latent variables; and</li><li id="ul0138-0002" num="0967">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, from the generated set of random values using a neural network decoder of the trained deep learning neural network associated with the time period bucket.</li></ul></li><li id="ul0129-0025" num="0968">112. The apparatus of embodiment 101, further, comprising:</li><li id="ul0129-0026" num="0969">the processor-executable instructions structured as: <ul id="ul0139" list-style="none"><li id="ul0139-0001" num="0970">filter, via at least one processor, the set of simulated market scenarios associated with the time period length based on specified ranges of allowable values for specified customized market factors.</li></ul></li><li id="ul0129-0027" num="0971">113. The apparatus of embodiment 101, further, comprising:</li><li id="ul0129-0028" num="0972">the processor-executable instructions structured as: <ul id="ul0140" list-style="none"><li id="ul0140-0001" num="0973">filter, via at least one processor, the set of simulated market scenarios associated with the time period length based on specified business cycle settings.</li></ul></li><li id="ul0129-0029" num="0974">114. The apparatus of embodiment 101, further, comprising:</li><li id="ul0129-0030" num="0975">the processor-executable instructions structured as: <ul id="ul0141" list-style="none"><li id="ul0141-0001" num="0976">initialize, via at least one processor, starting portfolio weights of securities in the universe of securities to benchmark portfolio weights of a benchmark portfolio.</li></ul></li><li id="ul0129-0031" num="0977">115. The apparatus of embodiment 101, further, comprising:</li><li id="ul0129-0032" num="0978">the portfolio weights of securities in the universe of securities are structured to be optimized by finding a mixed integer linear programming portfolio solution.</li><li id="ul0129-0033" num="0979">116. A machine learning portfolio generating processor-readable, non-transient medium, comprising processor-executable instructions structured as: <ul id="ul0142" list-style="none"><li id="ul0142-0001" num="0980">obtain, via at least one processor, a portfolio construction request datastructure, the portfolio construction request datastructure structured to include a set of optimization parameters including a universe of securities, a time period length, a conditional value at risk portion, a conditional value at risk threshold, a portfolio value amount;</li><li id="ul0142-0002" num="0981">determine, via at least one processor, a set of simulated market scenarios associated with the time period length, the set of simulated market scenarios generated using a set of deep learning neural networks, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values;</li><li id="ul0142-0003" num="0982">retrieve, via at least one processor, a set of expected returns for securities in the universe of securities for the set of simulated market scenarios, each expected return in the set of expected returns configured as calculated for a security during a simulated market scenario using: <ul id="ul0143" list-style="none"><li id="ul0143-0001" num="0983">the respective security's conditional Beta during the respective simulated market scenario, determined using a set of decision tree ensembles, trained to estimate conditional Beta of the respective security, based on a first subset of the set of simulated market factor values, and</li><li id="ul0143-0002" num="0984">the respective security's conditional default probability during the respective simulated market scenario, determined using a set of decision tree ensembles, trained to estimate conditional default probability of the respective security, based on a second subset of the set of simulated market factor values;</li></ul></li><li id="ul0142-0004" num="0985">optimize, via at least one processor, portfolio weights of securities in the universe of securities in accordance with the conditional value at risk portion, the conditional value at risk threshold, and the portfolio value amount, using the set of expected returns, to generate a set of tradeable transactions that maximize expected portfolio return of an optimized portfolio; and</li><li id="ul0142-0005" num="0986">execute, via at least one processor, the set of tradeable transactions to generate the optimized portfolio.</li></ul></li><li id="ul0129-0034" num="0987">117. The medium of embodiment 116, further, comprising:</li><li id="ul0129-0035" num="0988">the instructions to generate the set of simulated market scenarios using the set of deep learning neural networks are structured to comprise instructions to: <ul id="ul0144" list-style="none"><li id="ul0144-0001" num="0989">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0144-0002" num="0990">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0144-0003" num="0991">train, via at least one processor, for each time period bucket from the set of time period buckets, a deep learning neural network, from the set of deep learning neural networks, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0144-0004" num="0992">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained deep learning neural network associated with the respective time period bucket; and</li><li id="ul0144-0005" num="0993">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained deep learning neural network associated with the respective time period bucket.</li></ul></li><li id="ul0129-0036" num="0994">118. The medium of embodiment 117, further, comprising:</li><li id="ul0129-0037" num="0995">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0145" list-style="none"><li id="ul0145-0001" num="0996">determine, via at least one processor, a historical data set, a rolling window period length, and a set of market factors;</li><li id="ul0145-0002" num="0997">determine, via at least one processor, a set of rolling window periods using the historical data set and the rolling window period length; and</li><li id="ul0145-0003" num="0998">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0146" list-style="none"><li id="ul0146-0001" num="0999">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0038" num="1000">119. The medium of embodiment 118, further, comprising:</li><li id="ul0129-0039" num="1001">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0147" list-style="none"><li id="ul0147-0001" num="1002">determine, via at least one processor, the delta between values of the market factor at a beginning time point and an ending time point of the rolling window period.</li></ul></li><li id="ul0129-0040" num="1003">120. The medium of embodiment 119, further, comprising:</li><li id="ul0129-0041" num="1004">the processor-executable instructions structured as: <ul id="ul0148" list-style="none"><li id="ul0148-0001" num="1005">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0148-0002" num="1006">impute, via at least one processor, the unavailable historical data for the time point using a machine learning method.</li></ul></li><li id="ul0129-0042" num="1007">121. The medium of embodiment 118, further, comprising:</li><li id="ul0129-0043" num="1008">the rolling window period length is structured to be equal to the time period length.</li><li id="ul0129-0044" num="1009">122. The medium of embodiment 117, further, comprising:</li><li id="ul0129-0045" num="1010">the set of time period buckets is structured to have an equal fixed length for each time period bucket.</li><li id="ul0129-0046" num="1011">123. The medium of embodiment 117, further, comprising:</li><li id="ul0129-0047" num="1012">the set of time period buckets is structured to have a variable length for each time period bucket, the variable length for each time period bucket determined by judging the overall goodness of fit between the set of simulated market scenarios and the set of historical market scenarios.</li><li id="ul0129-0048" num="1013">124. The medium of embodiment 117, further, comprising:</li><li id="ul0129-0049" num="1014">the instructions to train a deep learning neural network for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0149" list-style="none"><li id="ul0149-0001" num="1015">select, via at least one processor, a historical market scenario from the associated subset of historical market scenarios; and</li><li id="ul0149-0002" num="1016">train, via at least one processor, the deep learning neural network for the time period bucket on the selected historical market scenario using a variational autoencoder.</li></ul></li><li id="ul0129-0050" num="1017">125. The medium of embodiment 124, further, comprising:</li><li id="ul0129-0051" num="1018">the deep learning neural network for the time period bucket is trained to generate a set of Gaussian mixture latent variables.</li><li id="ul0129-0052" num="1019">126. The medium of embodiment 125, further, comprising:</li><li id="ul0129-0053" num="1020">the instructions to generate simulated market scenarios for the time period bucket, using the trained deep learning neural network associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0150" list-style="none"><li id="ul0150-0001" num="1021">generate, via at least one processor, a set of random values for the set of Gaussian mixture latent variables; and</li><li id="ul0150-0002" num="1022">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, from the generated set of random values using a neural network decoder of the trained deep learning neural network associated with the time period bucket.</li></ul></li><li id="ul0129-0054" num="1023">127. The medium of embodiment 116, further, comprising:</li><li id="ul0129-0055" num="1024">the processor-executable instructions structured as: <ul id="ul0151" list-style="none"><li id="ul0151-0001" num="1025">filter, via at least one processor, the set of simulated market scenarios associated with the time period length based on specified ranges of allowable values for specified customized market factors.</li></ul></li><li id="ul0129-0056" num="1026">128. The medium of embodiment 116, further, comprising:</li><li id="ul0129-0057" num="1027">the processor-executable instructions structured as: <ul id="ul0152" list-style="none"><li id="ul0152-0001" num="1028">filter, via at least one processor, the set of simulated market scenarios associated with the time period length based on specified business cycle settings.</li></ul></li><li id="ul0129-0058" num="1029">129. The medium of embodiment 116, further, comprising:</li><li id="ul0129-0059" num="1030">the processor-executable instructions structured as: <ul id="ul0153" list-style="none"><li id="ul0153-0001" num="1031">initialize, via at least one processor, starting portfolio weights of securities in the universe of securities to benchmark portfolio weights of a benchmark portfolio.</li></ul></li><li id="ul0129-0060" num="1032">130. The medium of embodiment 116, further, comprising:</li><li id="ul0129-0061" num="1033">the portfolio weights of securities in the universe of securities are structured to be optimized by finding a mixed integer linear programming portfolio solution.</li><li id="ul0129-0062" num="1034">131. A machine learning portfolio generating processor-implemented system, comprising:</li><li id="ul0129-0063" num="1035">means to process processor-executable instructions;</li><li id="ul0129-0064" num="1036">means to issue processor-issuable instructions from a processor-executable component collection via the means to process processor-executable instructions, the processor-issuable instructions structured as: <ul id="ul0154" list-style="none"><li id="ul0154-0001" num="1037">obtain, via at least one processor, a portfolio construction request datastructure, the portfolio construction request datastructure structured to include a set of optimization parameters including a universe of securities, a time period length, a conditional value at risk portion, a conditional value at risk threshold, a portfolio value amount;</li><li id="ul0154-0002" num="1038">determine, via at least one processor, a set of simulated market scenarios associated with the time period length, the set of simulated market scenarios generated using a set of deep learning neural networks, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values;</li><li id="ul0154-0003" num="1039">retrieve, via at least one processor, a set of expected returns for securities in the universe of securities for the set of simulated market scenarios, each expected return in the set of expected returns configured as calculated for a security during a simulated market scenario using: <ul id="ul0155" list-style="none"><li id="ul0155-0001" num="1040">the respective security's conditional Beta during the respective simulated market scenario, determined using a set of decision tree ensembles, trained to estimate conditional Beta of the respective security, based on a first subset of the set of simulated market factor values, and</li><li id="ul0155-0002" num="1041">the respective security's conditional default probability during the respective simulated market scenario, determined using a set of decision tree ensembles, trained to estimate conditional default probability of the respective security, based on a second subset of the set of simulated market factor values;</li></ul></li><li id="ul0154-0004" num="1042">optimize, via at least one processor, portfolio weights of securities in the universe of securities in accordance with the conditional value at risk portion, the conditional value at risk threshold, and the portfolio value amount, using the set of expected returns, to generate a set of tradeable transactions that maximize expected portfolio return of an optimized portfolio; and</li><li id="ul0154-0005" num="1043">execute, via at least one processor, the set of tradeable transactions to generate the optimized portfolio.</li></ul></li><li id="ul0129-0065" num="1044">132. The system of embodiment 131, further, comprising:</li><li id="ul0129-0066" num="1045">the instructions to generate the set of simulated market scenarios using the set of deep learning neural networks are structured to comprise instructions to: <ul id="ul0156" list-style="none"><li id="ul0156-0001" num="1046">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0156-0002" num="1047">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0156-0003" num="1048">train, via at least one processor, for each time period bucket from the set of time period buckets, a deep learning neural network, from the set of deep learning neural networks, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0156-0004" num="1049">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained deep learning neural network associated with the respective time period bucket; and</li><li id="ul0156-0005" num="1050">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained deep learning neural network associated with the respective time period bucket.</li></ul></li><li id="ul0129-0067" num="1051">133. The system of embodiment 132, further, comprising:</li><li id="ul0129-0068" num="1052">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0157" list-style="none"><li id="ul0157-0001" num="1053">determine, via at least one processor, a historical data set, a rolling window period length, and a set of market factors;</li><li id="ul0157-0002" num="1054">determine, via at least one processor, a set of rolling window periods using the historical data set and the rolling window period length; and</li><li id="ul0157-0003" num="1055">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0158" list-style="none"><li id="ul0158-0001" num="1056">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0069" num="1057">134. The system of embodiment 133, further, comprising:</li><li id="ul0129-0070" num="1058">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0159" list-style="none"><li id="ul0159-0001" num="1059">determine, via at least one processor, the delta between values of the market factor at a beginning time point and an ending time point of the rolling window period.</li></ul></li><li id="ul0129-0071" num="1060">135. The system of embodiment 134, further, comprising:</li><li id="ul0129-0072" num="1061">the processor-executable instructions structured as: <ul id="ul0160" list-style="none"><li id="ul0160-0001" num="1062">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0160-0002" num="1063">impute, via at least one processor, the unavailable historical data for the time point using a machine learning method.</li></ul></li><li id="ul0129-0073" num="1064">136. The system of embodiment 133, further, comprising:</li><li id="ul0129-0074" num="1065">the rolling window period length is structured to be equal to the time period length.</li><li id="ul0129-0075" num="1066">137. The system of embodiment 132, further, comprising:</li><li id="ul0129-0076" num="1067">the set of time period buckets is structured to have an equal fixed length for each time period bucket.</li><li id="ul0129-0077" num="1068">138. The system of embodiment 132, further, comprising:</li><li id="ul0129-0078" num="1069">the set of time period buckets is structured to have a variable length for each time period bucket, the variable length for each time period bucket determined by judging the overall goodness of fit between the set of simulated market scenarios and the set of historical market scenarios.</li><li id="ul0129-0079" num="1070">139. The system of embodiment 132, further, comprising:</li><li id="ul0129-0080" num="1071">the instructions to train a deep learning neural network for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0161" list-style="none"><li id="ul0161-0001" num="1072">select, via at least one processor, a historical market scenario from the associated subset of historical market scenarios; and</li><li id="ul0161-0002" num="1073">train, via at least one processor, the deep learning neural network for the time period bucket on the selected historical market scenario using a variational autoencoder.</li></ul></li><li id="ul0129-0081" num="1074">140. The system of embodiment 139, further, comprising:</li><li id="ul0129-0082" num="1075">the deep learning neural network for the time period bucket is trained to generate a set of Gaussian mixture latent variables.</li><li id="ul0129-0083" num="1076">141. The system of embodiment 140, further, comprising:</li><li id="ul0129-0084" num="1077">the instructions to generate simulated market scenarios for the time period bucket, using the trained deep learning neural network associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0162" list-style="none"><li id="ul0162-0001" num="1078">generate, via at least one processor, a set of random values for the set of Gaussian mixture latent variables; and</li><li id="ul0162-0002" num="1079">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, from the generated set of random values using a neural network decoder of the trained deep learning neural network associated with the time period bucket.</li></ul></li><li id="ul0129-0085" num="1080">142. The system of embodiment 131, further, comprising:</li><li id="ul0129-0086" num="1081">the processor-executable instructions structured as: <ul id="ul0163" list-style="none"><li id="ul0163-0001" num="1082">filter, via at least one processor, the set of simulated market scenarios associated with the time period length based on specified ranges of allowable values for specified customized market factors.</li></ul></li><li id="ul0129-0087" num="1083">143. The system of embodiment 131, further, comprising:</li><li id="ul0129-0088" num="1084">the processor-executable instructions structured as: <ul id="ul0164" list-style="none"><li id="ul0164-0001" num="1085">filter, via at least one processor, the set of simulated market scenarios associated with the time period length based on specified business cycle settings.</li></ul></li><li id="ul0129-0089" num="1086">144. The system of embodiment 131, further, comprising:</li><li id="ul0129-0090" num="1087">the processor-executable instructions structured as: <ul id="ul0165" list-style="none"><li id="ul0165-0001" num="1088">initialize, via at least one processor, starting portfolio weights of securities in the universe of securities to benchmark portfolio weights of a benchmark portfolio.</li></ul></li><li id="ul0129-0091" num="1089">145. The system of embodiment 131, further, comprising:</li><li id="ul0129-0092" num="1090">the portfolio weights of securities in the universe of securities are structured to be optimized by finding a mixed integer linear programming portfolio solution.</li><li id="ul0129-0093" num="1091">146. A machine learning portfolio generating processor-implemented process, comprising executing processor-executable instructions to: <ul id="ul0166" list-style="none"><li id="ul0166-0001" num="1092">obtain, via at least one processor, a portfolio construction request datastructure, the portfolio construction request datastructure structured to include a set of optimization parameters including a universe of securities, a time period length, a conditional value at risk portion, a conditional value at risk threshold, a portfolio value amount;</li><li id="ul0166-0002" num="1093">determine, via at least one processor, a set of simulated market scenarios associated with the time period length, the set of simulated market scenarios generated using a set of deep learning neural networks, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values;</li><li id="ul0166-0003" num="1094">retrieve, via at least one processor, a set of expected returns for securities in the universe of securities for the set of simulated market scenarios, each expected return in the set of expected returns configured as calculated for a security during a simulated market scenario using: <ul id="ul0167" list-style="none"><li id="ul0167-0001" num="1095">the respective security's conditional Beta during the respective simulated market scenario, determined using a set of decision tree ensembles, trained to estimate conditional Beta of the respective security, based on a first subset of the set of simulated market factor values, and</li><li id="ul0167-0002" num="1096">the respective security's conditional default probability during the respective simulated market scenario, determined using a set of decision tree ensembles, trained to estimate conditional default probability of the respective security, based on a second subset of the set of simulated market factor values;</li></ul></li><li id="ul0166-0004" num="1097">optimize, via at least one processor, portfolio weights of securities in the universe of securities in accordance with the conditional value at risk portion, the conditional value at risk threshold, and the portfolio value amount, using the set of expected returns, to generate a set of tradeable transactions that maximize expected portfolio return of an optimized portfolio; and</li><li id="ul0166-0005" num="1098">execute, via at least one processor, the set of tradeable transactions to generate the optimized portfolio.</li></ul></li><li id="ul0129-0094" num="1099">147. The process of embodiment 146, further, comprising:</li><li id="ul0129-0095" num="1100">the instructions to generate the set of simulated market scenarios using the set of deep learning neural networks are structured to comprise instructions to: <ul id="ul0168" list-style="none"><li id="ul0168-0001" num="1101">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0168-0002" num="1102">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0168-0003" num="1103">train, via at least one processor, for each time period bucket from the set of time period buckets, a deep learning neural network, from the set of deep learning neural networks, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0168-0004" num="1104">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained deep learning neural network associated with the respective time period bucket; and</li><li id="ul0168-0005" num="1105">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained deep learning neural network associated with the respective time period bucket.</li></ul></li><li id="ul0129-0096" num="1106">148. The process of embodiment 147, further, comprising:</li><li id="ul0129-0097" num="1107">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0169" list-style="none"><li id="ul0169-0001" num="1108">determine, via at least one processor, a historical data set, a rolling window period length, and a set of market factors;</li><li id="ul0169-0002" num="1109">determine, via at least one processor, a set of rolling window periods using the historical data set and the rolling window period length; and</li><li id="ul0169-0003" num="1110">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0170" list-style="none"><li id="ul0170-0001" num="1111">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0098" num="1112">149. The process of embodiment 148, further, comprising:</li><li id="ul0129-0099" num="1113">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0171" list-style="none"><li id="ul0171-0001" num="1114">determine, via at least one processor, the delta between values of the market factor at a beginning time point and an ending time point of the rolling window period.</li></ul></li><li id="ul0129-0100" num="1115">150. The process of embodiment 149, further, comprising:</li><li id="ul0129-0101" num="1116">the processor-executable instructions structured as: <ul id="ul0172" list-style="none"><li id="ul0172-0001" num="1117">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0172-0002" num="1118">impute, via at least one processor, the unavailable historical data for the time point using a machine learning method.</li></ul></li><li id="ul0129-0102" num="1119">151. The process of embodiment 148, further, comprising:</li><li id="ul0129-0103" num="1120">the rolling window period length is structured to be equal to the time period length.</li><li id="ul0129-0104" num="1121">152. The process of embodiment 147, further, comprising:</li><li id="ul0129-0105" num="1122">the set of time period buckets is structured to have an equal fixed length for each time period bucket.</li><li id="ul0129-0106" num="1123">153. The process of embodiment 147, further, comprising:</li><li id="ul0129-0107" num="1124">the set of time period buckets is structured to have a variable length for each time period bucket, the variable length for each time period bucket determined by judging the overall goodness of fit between the set of simulated market scenarios and the set of historical market scenarios.</li><li id="ul0129-0108" num="1125">154. The process of embodiment 147, further, comprising:</li><li id="ul0129-0109" num="1126">the instructions to train a deep learning neural network for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0173" list-style="none"><li id="ul0173-0001" num="1127">select, via at least one processor, a historical market scenario from the associated subset of historical market scenarios; and</li><li id="ul0173-0002" num="1128">train, via at least one processor, the deep learning neural network for the time period bucket on the selected historical market scenario using a variational autoencoder.</li></ul></li><li id="ul0129-0110" num="1129">155. The process of embodiment 154, further, comprising:</li><li id="ul0129-0111" num="1130">the deep learning neural network for the time period bucket is trained to generate a set of Gaussian mixture latent variables.</li><li id="ul0129-0112" num="1131">156. The process of embodiment 155, further, comprising:</li><li id="ul0129-0113" num="1132">the instructions to generate simulated market scenarios for the time period bucket, using the trained deep learning neural network associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0174" list-style="none"><li id="ul0174-0001" num="1133">generate, via at least one processor, a set of random values for the set of Gaussian mixture latent variables; and</li><li id="ul0174-0002" num="1134">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, from the generated set of random values using a neural network decoder of the trained deep learning neural network associated with the time period bucket.</li></ul></li><li id="ul0129-0114" num="1135">157. The process of embodiment 146, further, comprising:</li><li id="ul0129-0115" num="1136">the processor-executable instructions structured as: <ul id="ul0175" list-style="none"><li id="ul0175-0001" num="1137">filter, via at least one processor, the set of simulated market scenarios associated with the time period length based on specified ranges of allowable values for specified customized market factors.</li></ul></li><li id="ul0129-0116" num="1138">158. The process of embodiment 146, further, comprising:</li><li id="ul0129-0117" num="1139">the processor-executable instructions structured as: <ul id="ul0176" list-style="none"><li id="ul0176-0001" num="1140">filter, via at least one processor, the set of simulated market scenarios associated with the time period length based on specified business cycle settings.</li></ul></li><li id="ul0129-0118" num="1141">159. The process of embodiment 146, further, comprising:</li><li id="ul0129-0119" num="1142">the processor-executable instructions structured as: <ul id="ul0177" list-style="none"><li id="ul0177-0001" num="1143">initialize, via at least one processor, starting portfolio weights of securities in the universe of securities to benchmark portfolio weights of a benchmark portfolio.</li></ul></li><li id="ul0129-0120" num="1144">160. The process of embodiment 146, further, comprising:</li><li id="ul0129-0121" num="1145">the portfolio weights of securities in the universe of securities are structured to be optimized by finding a mixed integer linear programming portfolio solution.</li><li id="ul0129-0122" num="1146">201. A machine learning portfolio generating apparatus, comprising:</li><li id="ul0129-0123" num="1147">a memory;</li><li id="ul0129-0124" num="1148">a component collection in the memory;</li><li id="ul0129-0125" num="1149">a processor disposed in communication with the memory and configured to issue a plurality of processor-executable instructions from the component collection, the processor-executable instructions structured as: <ul id="ul0178" list-style="none"><li id="ul0178-0001" num="1150">obtain, via at least one processor, a portfolio construction request datastructure, the portfolio construction request datastructure structured to include a set of optimization parameters including a universe of securities, a time period length, a conditional value at risk portion, a conditional value at risk threshold, a portfolio value amount;</li><li id="ul0178-0002" num="1151">determine, via at least one processor, a set of simulated market scenarios associated with the time period length, the set of simulated market scenarios generated using a set of multi-variate mixture datastructures, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values;</li><li id="ul0178-0003" num="1152">retrieve, via at least one processor, a set of expected returns for securities in the universe of securities for the set of simulated market scenarios, each expected return in the set of expected returns configured as calculated for a security during a simulated market scenario using: <ul id="ul0179" list-style="none"><li id="ul0179-0001" num="1153">the respective security's conditional Beta during the respective simulated market scenario, determined using a set of decision tree ensembles, trained to estimate conditional Beta of the respective security, based on a first subset of the set of simulated market factor values, and</li><li id="ul0179-0002" num="1154">the respective security's conditional default probability during the respective simulated market scenario, determined using a set of decision tree ensembles, trained to estimate conditional default probability of the respective security, based on a second subset of the set of simulated market factor values;</li></ul></li><li id="ul0178-0004" num="1155">optimize, via at least one processor, portfolio weights of securities in the universe of securities in accordance with the conditional value at risk portion, the conditional value at risk threshold, and the portfolio value amount, using the set of expected returns, to generate a set of tradeable transactions that maximize expected portfolio return of an optimized portfolio; and</li><li id="ul0178-0005" num="1156">execute, via at least one processor, the set of tradeable transactions to generate the optimized portfolio.</li></ul></li><li id="ul0129-0126" num="1157">202. The apparatus of embodiment 201, further, comprising:</li><li id="ul0129-0127" num="1158">the instructions to generate the set of simulated market scenarios using the set of multi-variate mixture datastructures are structured to comprise instructions to <ul id="ul0180" list-style="none"><li id="ul0180-0001" num="1159">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0180-0002" num="1160">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0180-0003" num="1161">train, via at least one processor, for each time period bucket from the set of time period buckets, a multi-variate mixture datastructure, from the set of multi-variate mixture datastructures, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0180-0004" num="1162">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained multi-variate mixture datastructure associated with the respective time period bucket; and</li><li id="ul0180-0005" num="1163">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained multi-variate mixture datastructure associated with the respective time period bucket.</li></ul></li><li id="ul0129-0128" num="1164">203. The apparatus of embodiment 202, further, comprising:</li><li id="ul0129-0129" num="1165">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0181" list-style="none"><li id="ul0181-0001" num="1166">determine, via at least one processor, a historical data set and a set of market factors;</li><li id="ul0181-0002" num="1167">determine, via at least one processor, a set of rolling window periods for the historical data set; and</li><li id="ul0181-0003" num="1168">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period,</li><li id="ul0181-0004" num="1169">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li><li id="ul0129-0130" num="1170">204. The apparatus of embodiment 203, further, comprising:</li><li id="ul0129-0131" num="1171">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0182" list-style="none"><li id="ul0182-0001" num="1172">determine, via at least one processor, the delta between values of the market factor at two time point of the rolling window period.</li></ul></li><li id="ul0129-0132" num="1173">205. The apparatus of embodiment 204, further, comprising:</li><li id="ul0129-0133" num="1174">the processor-executable instructions structured as: <ul id="ul0183" list-style="none"><li id="ul0183-0001" num="1175">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0183-0002" num="1176">impute, via at least one processor, the unavailable historical data for the time point using a k-Nearest Neighbors method.</li></ul></li><li id="ul0129-0134" num="1177">206. The apparatus of embodiment 203, further, comprising:</li><li id="ul0129-0135" num="1178">the length of a rolling window period is structured to be equal to the time period length.</li><li id="ul0129-0136" num="1179">207. The apparatus of embodiment 202, further, comprising:</li><li id="ul0129-0137" num="1180">the set of time period buckets is structured to have a fixed length for each time period bucket.</li><li id="ul0129-0138" num="1181">208. The apparatus of embodiment 202, further, comprising:</li><li id="ul0129-0139" num="1182">the set of time period buckets is structured to have variable lengths, the variable length for each time period bucket reflective of changes in volatilities and correlations of the set of historical market scenarios.</li><li id="ul0129-0140" num="1183">209. The apparatus of embodiment 203, further, comprising:</li><li id="ul0129-0141" num="1184">the instructions to train a multi-variate mixture datastructure for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0184" list-style="none"><li id="ul0184-0001" num="1185">determine, via at least one processor, for each market factor from the set of market factors, a distribution to use for the respective market factor for the time period bucket;</li><li id="ul0184-0002" num="1186">fit, via at least one processor, for each market factor from the set of market factors, the distribution to use for the respective market factor for the time period bucket using the associated subset of historical market scenarios;</li><li id="ul0184-0003" num="1187">determine, via at least one processor, a copula for the set of market factors for the time period bucket; and</li><li id="ul0184-0004" num="1188">train, via at least one processor, the multi-variate mixture datastructure for the time period bucket using the fitted distributions and the copula for the set of market factors.</li></ul></li><li id="ul0129-0142" num="1189">210. The apparatus of embodiment 209, further, comprising:</li><li id="ul0129-0143" num="1190">the instructions to fit the distribution to use for a market factor for the time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to calculate the mean of the market factor's values in the associated subset of historical market scenarios.</li><li id="ul0129-0144" num="1191">211. The apparatus of embodiment 202, further, comprising:</li><li id="ul0129-0145" num="1192">the instructions to generate simulated market scenarios for a time period bucket, using the trained multi-variate mixture datastructure associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0185" list-style="none"><li id="ul0185-0001" num="1193">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, by sampling the trained multi-variate mixture datastructure associated with the time period bucket.</li></ul></li><li id="ul0129-0146" num="1194">212. The apparatus of embodiment 201, further, comprising:</li><li id="ul0129-0147" num="1195">the processor-executable instructions structured as: <ul id="ul0186" list-style="none"><li id="ul0186-0001" num="1196">filter, via at least one processor, the set of simulated market scenarios associated with the time period length based on specified ranges of allowable values for specified customized market factors.</li></ul></li><li id="ul0129-0148" num="1197">213. The apparatus of embodiment 201, further, comprising:</li><li id="ul0129-0149" num="1198">the processor-executable instructions structured as: <ul id="ul0187" list-style="none"><li id="ul0187-0001" num="1199">filter, via at least one processor, the set of simulated market scenarios associated with the time period length based on specified business cycle settings.</li></ul></li><li id="ul0129-0150" num="1200">214. The apparatus of embodiment 201, further, comprising:</li><li id="ul0129-0151" num="1201">the processor-executable instructions structured as: <ul id="ul0188" list-style="none"><li id="ul0188-0001" num="1202">initialize, via at least one processor, starting portfolio weights of securities in the universe of securities to benchmark portfolio weights of a benchmark portfolio.</li></ul></li><li id="ul0129-0152" num="1203">215. The apparatus of embodiment 201, further, comprising:</li><li id="ul0129-0153" num="1204">the portfolio weights of securities in the universe of securities are structured to be optimized by finding a mixed integer linear programming portfolio solution.</li><li id="ul0129-0154" num="1205">216. A machine learning portfolio generating processor-readable, non-transient medium, comprising processor-executable instructions structured as: <ul id="ul0189" list-style="none"><li id="ul0189-0001" num="1206">obtain, via at least one processor, a portfolio construction request datastructure, the portfolio construction request datastructure structured to include a set of optimization parameters including a universe of securities, a time period length, a conditional value at risk portion, a conditional value at risk threshold, a portfolio value amount;</li><li id="ul0189-0002" num="1207">determine, via at least one processor, a set of simulated market scenarios associated with the time period length, the set of simulated market scenarios generated using a set of multi-variate mixture datastructures, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values;</li><li id="ul0189-0003" num="1208">retrieve, via at least one processor, a set of expected returns for securities in the universe of securities for the set of simulated market scenarios, each expected return in the set of expected returns configured as calculated for a security during a simulated market scenario using: <ul id="ul0190" list-style="none"><li id="ul0190-0001" num="1209">the respective security's conditional Beta during the respective simulated market scenario, determined using a set of decision tree ensembles, trained to estimate conditional Beta of the respective security, based on a first subset of the set of simulated market factor values, and</li><li id="ul0190-0002" num="1210">the respective security's conditional default probability during the respective simulated market scenario, determined using a set of decision tree ensembles, trained to estimate conditional default probability of the respective security, based on a second subset of the set of simulated market factor values;</li></ul></li><li id="ul0189-0004" num="1211">optimize, via at least one processor, portfolio weights of securities in the universe of securities in accordance with the conditional value at risk portion, the conditional value at risk threshold, and the portfolio value amount, using the set of expected returns, to generate a set of tradeable transactions that maximize expected portfolio return of an optimized portfolio; and</li><li id="ul0189-0005" num="1212">execute, via at least one processor, the set of tradeable transactions to generate the optimized portfolio.</li></ul></li><li id="ul0129-0155" num="1213">217. The medium of embodiment 216, further, comprising:</li><li id="ul0129-0156" num="1214">the instructions to generate the set of simulated market scenarios using the set of multi-variate mixture datastructures are structured to comprise instructions to <ul id="ul0191" list-style="none"><li id="ul0191-0001" num="1215">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0191-0002" num="1216">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0191-0003" num="1217">train, via at least one processor, for each time period bucket from the set of time period buckets, a multi-variate mixture datastructure, from the set of multi-variate mixture datastructures, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0191-0004" num="1218">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained multi-variate mixture datastructure associated with the respective time period bucket; and</li><li id="ul0191-0005" num="1219">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained multi-variate mixture datastructure associated with the respective time period bucket.</li></ul></li><li id="ul0129-0157" num="1220">218. The medium of embodiment 217, further, comprising:</li><li id="ul0129-0158" num="1221">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0192" list-style="none"><li id="ul0192-0001" num="1222">determine, via at least one processor, a historical data set and a set of market factors;</li><li id="ul0192-0002" num="1223">determine, via at least one processor, a set of rolling window periods for the historical data set; and</li><li id="ul0192-0003" num="1224">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0193" list-style="none"><li id="ul0193-0001" num="1225">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0159" num="1226">219. The medium of embodiment 218, further, comprising:</li><li id="ul0129-0160" num="1227">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0194" list-style="none"><li id="ul0194-0001" num="1228">determine, via at least one processor, the delta between values of the market factor at two time point of the rolling window period.</li></ul></li><li id="ul0129-0161" num="1229">220. The medium of embodiment 219, further, comprising:</li><li id="ul0129-0162" num="1230">the processor-executable instructions structured as: <ul id="ul0195" list-style="none"><li id="ul0195-0001" num="1231">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0195-0002" num="1232">impute, via at least one processor, the unavailable historical data for the time point using a k-Nearest Neighbors method.</li></ul></li><li id="ul0129-0163" num="1233">221. The medium of embodiment 218, further, comprising:</li><li id="ul0129-0164" num="1234">the length of a rolling window period is structured to be equal to the time period length.</li><li id="ul0129-0165" num="1235">222. The medium of embodiment 217, further, comprising:</li><li id="ul0129-0166" num="1236">the set of time period buckets is structured to have a fixed length for each time period bucket.</li><li id="ul0129-0167" num="1237">223. The medium of embodiment 217, further, comprising:</li><li id="ul0129-0168" num="1238">the set of time period buckets is structured to have variable lengths, the variable length for each time period bucket reflective of changes in volatilities and correlations of the set of historical market scenarios.</li><li id="ul0129-0169" num="1239">224. The medium of embodiment 218, further, comprising:</li><li id="ul0129-0170" num="1240">the instructions to train a multi-variate mixture datastructure for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0196" list-style="none"><li id="ul0196-0001" num="1241">determine, via at least one processor, for each market factor from the set of market factors, a distribution to use for the respective market factor for the time period bucket;</li><li id="ul0196-0002" num="1242">fit, via at least one processor, for each market factor from the set of market factors, the distribution to use for the respective market factor for the time period bucket using the associated subset of historical market scenarios;</li><li id="ul0196-0003" num="1243">determine, via at least one processor, a copula for the set of market factors for the time period bucket; and</li><li id="ul0196-0004" num="1244">train, via at least one processor, the multi-variate mixture datastructure for the time period bucket using the fitted distributions and the copula for the set of market factors.</li></ul></li><li id="ul0129-0171" num="1245">225. The medium of embodiment 224, further, comprising:</li><li id="ul0129-0172" num="1246">the instructions to fit the distribution to use for a market factor for the time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to calculate the mean of the market factor's values in the associated subset of historical market scenarios.</li><li id="ul0129-0173" num="1247">226. The medium of embodiment 217, further, comprising:</li><li id="ul0129-0174" num="1248">the instructions to generate simulated market scenarios for a time period bucket, using the trained multi-variate mixture datastructure associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0197" list-style="none"><li id="ul0197-0001" num="1249">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, by sampling the trained multi-variate mixture datastructure associated with the time period bucket.</li></ul></li><li id="ul0129-0175" num="1250">227. The medium of embodiment 216, further, comprising:</li><li id="ul0129-0176" num="1251">the processor-executable instructions structured as: <ul id="ul0198" list-style="none"><li id="ul0198-0001" num="1252">filter, via at least one processor, the set of simulated market scenarios associated with the time period length based on specified ranges of allowable values for specified customized market factors.</li></ul></li><li id="ul0129-0177" num="1253">228. The medium of embodiment 216, further, comprising:</li><li id="ul0129-0178" num="1254">the processor-executable instructions structured as: <ul id="ul0199" list-style="none"><li id="ul0199-0001" num="1255">filter, via at least one processor, the set of simulated market scenarios associated with the time period length based on specified business cycle settings.</li></ul></li><li id="ul0129-0179" num="1256">229. The medium of embodiment 216, further, comprising:</li><li id="ul0129-0180" num="1257">the processor-executable instructions structured as: <ul id="ul0200" list-style="none"><li id="ul0200-0001" num="1258">initialize, via at least one processor, starting portfolio weights of securities in the universe of securities to benchmark portfolio weights of a benchmark portfolio.</li></ul></li><li id="ul0129-0181" num="1259">230. The medium of embodiment 216, further, comprising:</li><li id="ul0129-0182" num="1260">the portfolio weights of securities in the universe of securities are structured to be optimized by finding a mixed integer linear programming portfolio solution.</li><li id="ul0129-0183" num="1261">231. A machine learning portfolio generating processor-implemented system, comprising:</li><li id="ul0129-0184" num="1262">means to process processor-executable instructions; <ul id="ul0201" list-style="none"><li id="ul0201-0001" num="1263">means to issue processor-issuable instructions from a processor-executable component collection via the means to process processor-executable instructions, the processor-issuable instructions structured as:</li><li id="ul0201-0002" num="1264">obtain, via at least one processor, a portfolio construction request datastructure, the portfolio construction request datastructure structured to include a set of optimization parameters including a universe of securities, a time period length, a conditional value at risk portion, a conditional value at risk threshold, a portfolio value amount;</li><li id="ul0201-0003" num="1265">determine, via at least one processor, a set of simulated market scenarios associated with the time period length, the set of simulated market scenarios generated using a set of multi-variate mixture datastructures, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values;</li><li id="ul0201-0004" num="1266">retrieve, via at least one processor, a set of expected returns for securities in the universe of securities for the set of simulated market scenarios, each expected return in the set of expected returns configured as calculated for a security during a simulated market scenario using: <ul id="ul0202" list-style="none"><li id="ul0202-0001" num="1267">the respective security's conditional Beta during the respective simulated market scenario, determined using a set of decision tree ensembles, trained to estimate conditional Beta of the respective security, based on a first subset of the set of simulated market factor values, and</li><li id="ul0202-0002" num="1268">the respective security's conditional default probability during the respective simulated market scenario, determined using a set of decision tree ensembles, trained to estimate conditional default probability of the respective security, based on a second subset of the set of simulated market factor values;</li></ul></li><li id="ul0201-0005" num="1269">optimize, via at least one processor, portfolio weights of securities in the universe of securities in accordance with the conditional value at risk portion, the conditional value at risk threshold, and the portfolio value amount, using the set of expected returns, to generate a set of tradeable transactions that maximize expected portfolio return of an optimized portfolio; and</li><li id="ul0201-0006" num="1270">execute, via at least one processor, the set of tradeable transactions to generate the optimized portfolio.</li></ul></li><li id="ul0129-0185" num="1271">232. The system of embodiment 231, further, comprising:</li><li id="ul0129-0186" num="1272">the instructions to generate the set of simulated market scenarios using the set of multi-variate mixture datastructures are structured to comprise instructions to <ul id="ul0203" list-style="none"><li id="ul0203-0001" num="1273">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0203-0002" num="1274">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0203-0003" num="1275">train, via at least one processor, for each time period bucket from the set of time period buckets, a multi-variate mixture datastructure, from the set of multi-variate mixture datastructures, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0203-0004" num="1276">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained multi-variate mixture datastructure associated with the respective time period bucket; and</li><li id="ul0203-0005" num="1277">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained multi-variate mixture datastructure associated with the respective time period bucket.</li></ul></li><li id="ul0129-0187" num="1278">233. The system of embodiment 232, further, comprising:</li><li id="ul0129-0188" num="1279">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0204" list-style="none"><li id="ul0204-0001" num="1280">determine, via at least one processor, a historical data set and a set of market factors;</li><li id="ul0204-0002" num="1281">determine, via at least one processor, a set of rolling window periods for the historical data set; and</li><li id="ul0204-0003" num="1282">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period,</li><li id="ul0204-0004" num="1283">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li><li id="ul0129-0189" num="1284">234. The system of embodiment 233, further, comprising:</li><li id="ul0129-0190" num="1285">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0205" list-style="none"><li id="ul0205-0001" num="1286">determine, via at least one processor, the delta between values of the market factor at two time point of the rolling window period.</li></ul></li><li id="ul0129-0191" num="1287">235. The system of embodiment 234, further, comprising:</li><li id="ul0129-0192" num="1288">the processor-executable instructions structured as: <ul id="ul0206" list-style="none"><li id="ul0206-0001" num="1289">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0206-0002" num="1290">impute, via at least one processor, the unavailable historical data for the time point using a k-Nearest Neighbors method.</li></ul></li><li id="ul0129-0193" num="1291">236. The system of embodiment 233, further, comprising:</li><li id="ul0129-0194" num="1292">the length of a rolling window period is structured to be equal to the time period length.</li><li id="ul0129-0195" num="1293">237. The system of embodiment 232, further, comprising:</li><li id="ul0129-0196" num="1294">the set of time period buckets is structured to have a fixed length for each time period bucket.</li><li id="ul0129-0197" num="1295">238. The system of embodiment 232, further, comprising:</li><li id="ul0129-0198" num="1296">the set of time period buckets is structured to have variable lengths, the variable length for each time period bucket reflective of changes in volatilities and correlations of the set of historical market scenarios.</li><li id="ul0129-0199" num="1297">239. The system of embodiment 233, further, comprising:</li><li id="ul0129-0200" num="1298">the instructions to train a multi-variate mixture datastructure for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0207" list-style="none"><li id="ul0207-0001" num="1299">determine, via at least one processor, for each market factor from the set of market factors, a distribution to use for the respective market factor for the time period bucket;</li><li id="ul0207-0002" num="1300">fit, via at least one processor, for each market factor from the set of market factors, the distribution to use for the respective market factor for the time period bucket using the associated subset of historical market scenarios;</li><li id="ul0207-0003" num="1301">determine, via at least one processor, a copula for the set of market factors for the time period bucket; and</li><li id="ul0207-0004" num="1302">train, via at least one processor, the multi-variate mixture datastructure for the time period bucket using the fitted distributions and the copula for the set of market factors.</li></ul></li><li id="ul0129-0201" num="1303">240. The system of embodiment 239, further, comprising:</li><li id="ul0129-0202" num="1304">the instructions to fit the distribution to use for a market factor for the time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to calculate the mean of the market factor's values in the associated subset of historical market scenarios.</li><li id="ul0129-0203" num="1305">241. The system of embodiment 232, further, comprising:</li><li id="ul0129-0204" num="1306">the instructions to generate simulated market scenarios for a time period bucket, using the trained multi-variate mixture datastructure associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0208" list-style="none"><li id="ul0208-0001" num="1307">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, by sampling the trained multi-variate mixture datastructure associated with the time period bucket.</li></ul></li><li id="ul0129-0205" num="1308">242. The system of embodiment 231, further, comprising:</li><li id="ul0129-0206" num="1309">the processor-executable instructions structured as: <ul id="ul0209" list-style="none"><li id="ul0209-0001" num="1310">filter, via at least one processor, the set of simulated market scenarios associated with the time period length based on specified ranges of allowable values for specified customized market factors.</li></ul></li><li id="ul0129-0207" num="1311">243. The system of embodiment 231, further, comprising:</li><li id="ul0129-0208" num="1312">the processor-executable instructions structured as: <ul id="ul0210" list-style="none"><li id="ul0210-0001" num="1313">filter, via at least one processor, the set of simulated market scenarios associated with the time period length based on specified business cycle settings.</li></ul></li><li id="ul0129-0209" num="1314">244. The system of embodiment 231, further, comprising:</li><li id="ul0129-0210" num="1315">the processor-executable instructions structured as: <ul id="ul0211" list-style="none"><li id="ul0211-0001" num="1316">initialize, via at least one processor, starting portfolio weights of securities in the universe of securities to benchmark portfolio weights of a benchmark portfolio.</li></ul></li><li id="ul0129-0211" num="1317">245. The system of embodiment 231, further, comprising:</li><li id="ul0129-0212" num="1318">the portfolio weights of securities in the universe of securities are structured to be optimized by finding a mixed integer linear programming portfolio solution.</li><li id="ul0129-0213" num="1319">246. A machine learning portfolio generating processor-implemented process, comprising executing processor-executable instructions to: <ul id="ul0212" list-style="none"><li id="ul0212-0001" num="1320">obtain, via at least one processor, a portfolio construction request datastructure, the portfolio construction request datastructure structured to include a set of optimization parameters including a universe of securities, a time period length, a conditional value at risk portion, a conditional value at risk threshold, a portfolio value amount;</li><li id="ul0212-0002" num="1321">determine, via at least one processor, a set of simulated market scenarios associated with the time period length, the set of simulated market scenarios generated using a set of multi-variate mixture datastructures, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values;</li><li id="ul0212-0003" num="1322">retrieve, via at least one processor, a set of expected returns for securities in the universe of securities for the set of simulated market scenarios, each expected return in the set of expected returns configured as calculated for a security during a simulated market scenario using: <ul id="ul0213" list-style="none"><li id="ul0213-0001" num="1323">the respective security's conditional Beta during the respective simulated market scenario, determined using a set of decision tree ensembles, trained to estimate conditional Beta of the respective security, based on a first subset of the set of simulated market factor values, and</li><li id="ul0213-0002" num="1324">the respective security's conditional default probability during the respective simulated market scenario, determined using a set of decision tree ensembles, trained to estimate conditional default probability of the respective security, based on a second subset of the set of simulated market factor values;</li></ul></li><li id="ul0212-0004" num="1325">optimize, via at least one processor, portfolio weights of securities in the universe of securities in accordance with the conditional value at risk portion, the conditional value at risk threshold, and the portfolio value amount, using the set of expected returns, to generate a set of tradeable transactions that maximize expected portfolio return of an optimized portfolio; and</li><li id="ul0212-0005" num="1326">execute, via at least one processor, the set of tradeable transactions to generate the optimized portfolio.</li></ul></li><li id="ul0129-0214" num="1327">247. The process of embodiment 246, further, comprising:</li><li id="ul0129-0215" num="1328">the instructions to generate the set of simulated market scenarios using the set of multi-variate mixture datastructures are structured to comprise instructions to <ul id="ul0214" list-style="none"><li id="ul0214-0001" num="1329">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0214-0002" num="1330">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0214-0003" num="1331">train, via at least one processor, for each time period bucket from the set of time period buckets, a multi-variate mixture datastructure, from the set of multi-variate mixture datastructures, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0214-0004" num="1332">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained multi-variate mixture datastructure associated with the respective time period bucket; and</li><li id="ul0214-0005" num="1333">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained multi-variate mixture datastructure associated with the respective time period bucket.</li></ul></li><li id="ul0129-0216" num="1334">248. The process of embodiment 247, further, comprising:</li><li id="ul0129-0217" num="1335">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0215" list-style="none"><li id="ul0215-0001" num="1336">determine, via at least one processor, a historical data set and a set of market factors;</li><li id="ul0215-0002" num="1337">determine, via at least one processor, a set of rolling window periods for the historical data set; and</li><li id="ul0215-0003" num="1338">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0216" list-style="none"><li id="ul0216-0001" num="1339">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0218" num="1340">249. The process of embodiment 248, further, comprising:</li><li id="ul0129-0219" num="1341">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0217" list-style="none"><li id="ul0217-0001" num="1342">determine, via at least one processor, the delta between values of the market factor at two time point of the rolling window period.</li></ul></li><li id="ul0129-0220" num="1343">250. The process of embodiment 249, further, comprising:</li><li id="ul0129-0221" num="1344">the processor-executable instructions structured as: <ul id="ul0218" list-style="none"><li id="ul0218-0001" num="1345">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0218-0002" num="1346">impute, via at least one processor, the unavailable historical data for the time point using a k-Nearest Neighbors method.</li></ul></li><li id="ul0129-0222" num="1347">251. The process of embodiment 248, further, comprising:</li><li id="ul0129-0223" num="1348">the length of a rolling window period is structured to be equal to the time period length.</li><li id="ul0129-0224" num="1349">252. The process of embodiment 247, further, comprising:</li><li id="ul0129-0225" num="1350">the set of time period buckets is structured to have a fixed length for each time period bucket.</li><li id="ul0129-0226" num="1351">253. The process of embodiment 247, further, comprising:</li><li id="ul0129-0227" num="1352">the set of time period buckets is structured to have variable lengths, the variable length for each time period bucket reflective of changes in volatilities and correlations of the set of historical market scenarios.</li><li id="ul0129-0228" num="1353">254. The process of embodiment 248, further, comprising:</li><li id="ul0129-0229" num="1354">the instructions to train a multi-variate mixture datastructure for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0219" list-style="none"><li id="ul0219-0001" num="1355">determine, via at least one processor, for each market factor from the set of market factors, a distribution to use for the respective market factor for the time period bucket;</li><li id="ul0219-0002" num="1356">fit, via at least one processor, for each market factor from the set of market factors, the distribution to use for the respective market factor for the time period bucket using the associated subset of historical market scenarios;</li><li id="ul0219-0003" num="1357">determine, via at least one processor, a copula for the set of market factors for the time period bucket; and</li><li id="ul0219-0004" num="1358">train, via at least one processor, the multi-variate mixture datastructure for the time period bucket using the fitted distributions and the copula for the set of market factors.</li></ul></li><li id="ul0129-0230" num="1359">255. The process of embodiment 254, further, comprising:</li><li id="ul0129-0231" num="1360">the instructions to fit the distribution to use for a market factor for the time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to calculate the mean of the market factor's values in the associated subset of historical market scenarios.</li><li id="ul0129-0232" num="1361">256. The process of embodiment 247, further, comprising:</li><li id="ul0129-0233" num="1362">the instructions to generate simulated market scenarios for a time period bucket, using the trained multi-variate mixture datastructure associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0220" list-style="none"><li id="ul0220-0001" num="1363">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, by sampling the trained multi-variate mixture datastructure associated with the time period bucket.</li></ul></li><li id="ul0129-0234" num="1364">257. The process of embodiment 246, further, comprising:</li><li id="ul0129-0235" num="1365">the processor-executable instructions structured as: <ul id="ul0221" list-style="none"><li id="ul0221-0001" num="1366">filter, via at least one processor, the set of simulated market scenarios associated with the time period length based on specified ranges of allowable values for specified customized market factors.</li></ul></li><li id="ul0129-0236" num="1367">258. The process of embodiment 246, further, comprising:</li><li id="ul0129-0237" num="1368">the processor-executable instructions structured as: <ul id="ul0222" list-style="none"><li id="ul0222-0001" num="1369">filter, via at least one processor, the set of simulated market scenarios associated with the time period length based on specified business cycle settings.</li></ul></li><li id="ul0129-0238" num="1370">259. The process of embodiment 246, further, comprising:</li><li id="ul0129-0239" num="1371">the processor-executable instructions structured as: <ul id="ul0223" list-style="none"><li id="ul0223-0001" num="1372">initialize, via at least one processor, starting portfolio weights of securities in the universe of securities to benchmark portfolio weights of a benchmark portfolio.</li></ul></li><li id="ul0129-0240" num="1373">260. The process of embodiment 246, further, comprising:</li><li id="ul0129-0241" num="1374">the portfolio weights of securities in the universe of securities are structured to be optimized by finding a mixed integer linear programming portfolio solution.</li><li id="ul0129-0242" num="1375">301. A machine learning predefined scenario constructing apparatus, comprising:</li><li id="ul0129-0243" num="1376">a memory;</li><li id="ul0129-0244" num="1377">a component collection in the memory;</li><li id="ul0129-0245" num="1378">a processor disposed in communication with the memory and configured to issue a plurality of processor-executable instructions from the component collection, the processor-executable instructions structured as: <ul id="ul0224" list-style="none"><li id="ul0224-0001" num="1379">obtain, via at least one processor, a user selection of a set of simulated market scenarios via a simulation selection interaction-interface mechanism, the set of simulated market scenarios generated using a set of deep learning neural networks, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0224-0002" num="1380">determine, via at least one processor, a range of unfiltered simulated market factor values for each market factor from the set of market factors, the range of unfiltered simulated market factor values for a market factor structured to include a minimum simulated market factor value and a maximum simulated market factor value in the set of simulated market scenarios for the respective market factor;</li><li id="ul0224-0003" num="1381">generate, via at least one processor, a set of market factor interaction-interface mechanisms, each market factor interaction-interface mechanism in the set of market factor interaction-interface mechanisms structured to be associated with a market factor from the set of market factors and structured to display the range of unfiltered simulated market factor values for the respective market factor;</li><li id="ul0224-0004" num="1382">obtain, via at least one processor, a user modification to a range of allowable values of a market factor from the set of market factors via the market factor interaction-interface mechanism associated with the modified market factor;</li><li id="ul0224-0005" num="1383">update, via at least one processor, a set of customized market factors from the set of market factors based on the user modification;</li><li id="ul0224-0006" num="1384">determine, via at least one processor, a range of allowable values for each customized market factor from the set of customized market factors;</li><li id="ul0224-0007" num="1385">filter, via at least one processor, the set of simulated market scenarios based on the determined ranges of allowable values for the set of customized market factors to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each customized market factors from the set of customized market factors;</li><li id="ul0224-0008" num="1386">determine, via at least one processor, a range of filtered simulated market factor values for each market factor from the set of market factors, the range of filtered simulated market factor values for a market factor structured to include a minimum simulated market factor value and a maximum simulated market factor value in the set of filtered simulated market scenarios for the respective market factor; and</li><li id="ul0224-0009" num="1387">generate, via at least one processor, an updated set of market factor interaction-interface mechanisms, each updated market factor interaction-interface mechanism in the set of updated market factor interaction-interface mechanisms structured to be associated with a market factor from the set of market factors and structured to display the range of filtered simulated market factor values for the respective market factor.</li></ul></li><li id="ul0129-0246" num="1388">302. The apparatus of embodiment 301, further, comprising:</li><li id="ul0129-0247" num="1389">the instructions to generate the set of simulated market scenarios using the set of deep learning neural networks are structured to comprise instructions to: <ul id="ul0225" list-style="none"><li id="ul0225-0001" num="1390">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0225-0002" num="1391">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0225-0003" num="1392">train, via at least one processor, for each time period bucket from the set of time period buckets, a deep learning neural network, from the set of deep learning neural networks, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0225-0004" num="1393">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained deep learning neural network associated with the respective time period bucket; and</li><li id="ul0225-0005" num="1394">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained deep learning neural network associated with the respective time period bucket.</li></ul></li><li id="ul0129-0248" num="1395">303. The apparatus of embodiment 302, further, comprising:</li><li id="ul0129-0249" num="1396">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0226" list-style="none"><li id="ul0226-0001" num="1397">determine, via at least one processor, a historical data set, a rolling window period length, and the set of market factors;</li><li id="ul0226-0002" num="1398">determine, via at least one processor, a set of rolling window periods using the historical data set and the rolling window period length; and</li><li id="ul0226-0003" num="1399">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0227" list-style="none"><li id="ul0227-0001" num="1400">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0250" num="1401">304. The apparatus of embodiment 303, further, comprising:</li><li id="ul0129-0251" num="1402">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0228" list-style="none"><li id="ul0228-0001" num="1403">determine, via at least one processor, the delta between values of the market factor at a beginning time point and an ending time point of the rolling window period.</li></ul></li><li id="ul0129-0252" num="1404">305. The apparatus of embodiment 304, further, comprising:</li><li id="ul0129-0253" num="1405">the processor-executable instructions structured as: <ul id="ul0229" list-style="none"><li id="ul0229-0001" num="1406">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0229-0002" num="1407">impute, via at least one processor, the unavailable historical data for the time point using a machine learning method.</li></ul></li><li id="ul0129-0254" num="1408">306. The apparatus of embodiment 303, further, comprising:</li><li id="ul0129-0255" num="1409">the rolling window period length is structured to be equal to the time period length.</li><li id="ul0129-0256" num="1410">307. The apparatus of embodiment 302, further, comprising:</li><li id="ul0129-0257" num="1411">the set of time period buckets is structured to have an equal fixed length for each time period bucket.</li><li id="ul0129-0258" num="1412">308. The apparatus of embodiment 302, further, comprising:</li><li id="ul0129-0259" num="1413">the set of time period buckets is structured to have a variable length for each time period bucket, the variable length for each time period bucket determined by judging the overall goodness of fit between the set of simulated market scenarios and the set of historical market scenarios.</li><li id="ul0129-0260" num="1414">309. The apparatus of embodiment 302, further, comprising:</li><li id="ul0129-0261" num="1415">the instructions to train a deep learning neural network for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0230" list-style="none"><li id="ul0230-0001" num="1416">select, via at least one processor, a historical market scenario from the associated subset of historical market scenarios; and</li><li id="ul0230-0002" num="1417">train, via at least one processor, the deep learning neural network for the time period bucket on the selected historical market scenario using a variational autoencoder.</li></ul></li><li id="ul0129-0262" num="1418">310. The apparatus of embodiment 309, further, comprising:</li><li id="ul0129-0263" num="1419">the deep learning neural network for the time period bucket is trained to generate a set of Gaussian mixture latent variables.</li><li id="ul0129-0264" num="1420">311. The apparatus of embodiment 310, further, comprising:</li><li id="ul0129-0265" num="1421">the instructions to generate simulated market scenarios for the time period bucket, using the trained deep learning neural network associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0231" list-style="none"><li id="ul0231-0001" num="1422">generate, via at least one processor, a set of random values for the set of Gaussian mixture latent variables; and</li><li id="ul0231-0002" num="1423">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, from the generated set of random values using a neural network decoder of the trained deep learning neural network associated with the time period bucket.</li></ul></li><li id="ul0129-0266" num="1424">312. The apparatus of embodiment 301, further, comprising:</li><li id="ul0129-0267" num="1425">the simulation selection interaction-interface mechanism is structured to comprise a pricing date selection interaction-interface mechanism and a simulation model selection interaction-interface mechanism.</li><li id="ul0129-0268" num="1426">313. The apparatus of embodiment 301, further, comprising:</li><li id="ul0129-0269" num="1427">the range of unfiltered simulated market factor values for a market factor structured to include an average simulated market factor value in the set of simulated market scenarios for the market factor; and</li><li id="ul0129-0270" num="1428">the range of filtered simulated market factor values for the market factor structured to include an average value in the set of filtered simulated market scenarios for the market factor.</li><li id="ul0129-0271" num="1429">314. The apparatus of embodiment 301, further, comprising:</li><li id="ul0129-0272" num="1430">each market factor interaction-interface mechanism in the set of market factor interaction-interface mechanisms is structured to include a slider interaction-interface mechanism to affect user modification to a range of allowable values of a market factor associated with the respective market factor interaction-interface mechanism.</li><li id="ul0129-0273" num="1431">315. The apparatus of embodiment 301, further, comprising:</li><li id="ul0129-0274" num="1432">the instructions to update the set of customized market factors based on the user modification are structured to comprise instructions to add the modified market factor to the set of customized market factors.</li><li id="ul0129-0275" num="1433">316. The apparatus of embodiment 301, further, comprising:</li><li id="ul0129-0276" num="1434">the instructions to update the set of customized market factors based on the user modification are structured to comprise instructions to remove the modified market factor from the set of customized market factors.</li><li id="ul0129-0277" num="1435">317. The apparatus of embodiment 301, further, comprising:</li><li id="ul0129-0278" num="1436">the processor-executable instructions structured as: <ul id="ul0232" list-style="none"><li id="ul0232-0001" num="1437">generate, via at least one processor, a predefined scenario datastructure that includes a simulation identifier associated with the set of simulated market scenarios, identifiers of customized market factors from the set of customized market factors, and the ranges of allowable values for the set of customized market factors.</li></ul></li><li id="ul0129-0279" num="1438">318. The apparatus of embodiment 301, further, comprising:</li><li id="ul0129-0280" num="1439">the processor-executable instructions structured as: <ul id="ul0233" list-style="none"><li id="ul0233-0001" num="1440">generate, via at least one processor, a predefined scenario datastructure that includes a simulation identifier associated with the set of simulated market scenarios, and identifiers of filtered simulated market scenarios from the set of filtered simulated market scenarios.</li></ul></li><li id="ul0129-0281" num="1441">319. The apparatus of embodiment 301, further, comprising:</li><li id="ul0129-0282" num="1442">the processor-executable instructions structured as: <ul id="ul0234" list-style="none"><li id="ul0234-0001" num="1443">generate, via at least one processor, a set of factor group filter interaction-interface mechanisms, each factor group filter interaction-interface mechanism in the set of factor group filter interaction-interface mechanisms structured to be associated with a subset of market factor interaction-interface mechanisms from the set of market factor interaction-interface mechanisms.</li></ul></li><li id="ul0129-0283" num="1444">320. The apparatus of embodiment 319, further, comprising:</li><li id="ul0129-0284" num="1445">the processor-executable instructions structured as: <ul id="ul0235" list-style="none"><li id="ul0235-0001" num="1446">obtain, via at least one processor, a user selection of a factor group filter interaction-interface mechanism in the set of factor group filter interaction-interface mechanisms; and</li><li id="ul0235-0002" num="1447">generate, via at least one processor, a filtered set of market factor interaction-interface mechanisms, each filtered market factor interaction-interface mechanism in the set of filtered market factor interaction-interface mechanisms structured to be associated with the selected factor group filter interaction-interface mechanism.</li></ul></li><li id="ul0129-0285" num="1448">321. A machine learning predefined scenario constructing processor-readable, non-transient medium, comprising processor-executable instructions structured as: <ul id="ul0236" list-style="none"><li id="ul0236-0001" num="1449">obtain, via at least one processor, a user selection of a set of simulated market scenarios via a simulation selection interaction-interface mechanism, the set of simulated market scenarios generated using a set of deep learning neural networks, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0236-0002" num="1450">determine, via at least one processor, a range of unfiltered simulated market factor values for each market factor from the set of market factors, the range of unfiltered simulated market factor values for a market factor structured to include a minimum simulated market factor value and a maximum simulated market factor value in the set of simulated market scenarios for the respective market factor;</li><li id="ul0236-0003" num="1451">generate, via at least one processor, a set of market factor interaction-interface mechanisms, each market factor interaction-interface mechanism in the set of market factor interaction-interface mechanisms structured to be associated with a market factor from the set of market factors and structured to display the range of unfiltered simulated market factor values for the respective market factor;</li><li id="ul0236-0004" num="1452">obtain, via at least one processor, a user modification to a range of allowable values of a market factor from the set of market factors via the market factor interaction-interface mechanism associated with the modified market factor;</li><li id="ul0236-0005" num="1453">update, via at least one processor, a set of customized market factors from the set of market factors based on the user modification;</li><li id="ul0236-0006" num="1454">determine, via at least one processor, a range of allowable values for each customized market factor from the set of customized market factors;</li><li id="ul0236-0007" num="1455">filter, via at least one processor, the set of simulated market scenarios based on the determined ranges of allowable values for the set of customized market factors to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each customized market factors from the set of customized market factors;</li><li id="ul0236-0008" num="1456">determine, via at least one processor, a range of filtered simulated market factor values for each market factor from the set of market factors, the range of filtered simulated market factor values for a market factor structured to include a minimum simulated market factor value and a maximum simulated market factor value in the set of filtered simulated market scenarios for the respective market factor; and</li><li id="ul0236-0009" num="1457">generate, via at least one processor, an updated set of market factor interaction-interface mechanisms, each updated market factor interaction-interface mechanism in the set of updated market factor interaction-interface mechanisms structured to be associated with a market factor from the set of market factors and structured to display the range of filtered simulated market factor values for the respective market factor.</li></ul></li><li id="ul0129-0286" num="1458">322. The medium of embodiment 321, further, comprising:</li><li id="ul0129-0287" num="1459">the instructions to generate the set of simulated market scenarios using the set of deep learning neural networks are structured to comprise instructions to: <ul id="ul0237" list-style="none"><li id="ul0237-0001" num="1460">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0237-0002" num="1461">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0237-0003" num="1462">train, via at least one processor, for each time period bucket from the set of time period buckets, a deep learning neural network, from the set of deep learning neural networks, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0237-0004" num="1463">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained deep learning neural network associated with the respective time period bucket; and</li><li id="ul0237-0005" num="1464">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained deep learning neural network associated with the respective time period bucket.</li></ul></li><li id="ul0129-0288" num="1465">323. The medium of embodiment 322, further, comprising:</li><li id="ul0129-0289" num="1466">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0238" list-style="none"><li id="ul0238-0001" num="1467">determine, via at least one processor, a historical data set, a rolling window period length, and the set of market factors;</li><li id="ul0238-0002" num="1468">determine, via at least one processor, a set of rolling window periods using the historical data set and the rolling window period length; and</li><li id="ul0238-0003" num="1469">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0239" list-style="none"><li id="ul0239-0001" num="1470">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0290" num="1471">324. The medium of embodiment 323, further, comprising:</li><li id="ul0129-0291" num="1472">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0240" list-style="none"><li id="ul0240-0001" num="1473">determine, via at least one processor, the delta between values of the market factor at a beginning time point and an ending time point of the rolling window period.</li></ul></li><li id="ul0129-0292" num="1474">325. The medium of embodiment 324, further, comprising:</li><li id="ul0129-0293" num="1475">the processor-executable instructions structured as: <ul id="ul0241" list-style="none"><li id="ul0241-0001" num="1476">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0241-0002" num="1477">impute, via at least one processor, the unavailable historical data for the time point using a machine learning method.</li></ul></li><li id="ul0129-0294" num="1478">326. The medium of embodiment 323, further, comprising:</li><li id="ul0129-0295" num="1479">the rolling window period length is structured to be equal to the time period length.</li><li id="ul0129-0296" num="1480">327. The medium of embodiment 322, further, comprising:</li><li id="ul0129-0297" num="1481">the set of time period buckets is structured to have an equal fixed length for each time period bucket.</li><li id="ul0129-0298" num="1482">328. The medium of embodiment 322, further, comprising:</li><li id="ul0129-0299" num="1483">the set of time period buckets is structured to have a variable length for each time period bucket, the variable length for each time period bucket determined by judging the overall goodness of fit between the set of simulated market scenarios and the set of historical market scenarios.</li><li id="ul0129-0300" num="1484">329. The medium of embodiment 322, further, comprising:</li><li id="ul0129-0301" num="1485">the instructions to train a deep learning neural network for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0242" list-style="none"><li id="ul0242-0001" num="1486">select, via at least one processor, a historical market scenario from the associated subset of historical market scenarios; and</li><li id="ul0242-0002" num="1487">train, via at least one processor, the deep learning neural network for the time period bucket on the selected historical market scenario using a variational autoencoder.</li></ul></li><li id="ul0129-0302" num="1488">330. The medium of embodiment 329, further, comprising:</li><li id="ul0129-0303" num="1489">the deep learning neural network for the time period bucket is trained to generate a set of Gaussian mixture latent variables.</li><li id="ul0129-0304" num="1490">331. The medium of embodiment 330, further, comprising:</li><li id="ul0129-0305" num="1491">the instructions to generate simulated market scenarios for the time period bucket, using the trained deep learning neural network associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0243" list-style="none"><li id="ul0243-0001" num="1492">generate, via at least one processor, a set of random values for the set of Gaussian mixture latent variables; and</li><li id="ul0243-0002" num="1493">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, from the generated set of random values using a neural network decoder of the trained deep learning neural network associated with the time period bucket.</li></ul></li><li id="ul0129-0306" num="1494">332. The medium of embodiment 321, further, comprising:</li><li id="ul0129-0307" num="1495">the simulation selection interaction-interface mechanism is structured to comprise a pricing date selection interaction-interface mechanism and a simulation model selection interaction-interface mechanism.</li><li id="ul0129-0308" num="1496">333. The medium of embodiment 321, further, comprising:</li><li id="ul0129-0309" num="1497">the range of unfiltered simulated market factor values for a market factor structured to include an average simulated market factor value in the set of simulated market scenarios for the market factor; and</li><li id="ul0129-0310" num="1498">the range of filtered simulated market factor values for the market factor structured to include an average value in the set of filtered simulated market scenarios for the market factor.</li><li id="ul0129-0311" num="1499">334. The medium of embodiment 321, further, comprising:</li><li id="ul0129-0312" num="1500">each market factor interaction-interface mechanism in the set of market factor interaction-interface mechanisms is structured to include a slider interaction-interface mechanism to affect user modification to a range of allowable values of a market factor associated with the respective market factor interaction-interface mechanism.</li><li id="ul0129-0313" num="1501">335. The medium of embodiment 321, further, comprising:</li><li id="ul0129-0314" num="1502">the instructions to update the set of customized market factors based on the user modification are structured to comprise instructions to add the modified market factor to the set of customized market factors.</li><li id="ul0129-0315" num="1503">336. The medium of embodiment 321, further, comprising:</li><li id="ul0129-0316" num="1504">the instructions to update the set of customized market factors based on the user modification are structured to comprise instructions to remove the modified market factor from the set of customized market factors.</li><li id="ul0129-0317" num="1505">337. The medium of embodiment 321, further, comprising:</li><li id="ul0129-0318" num="1506">the processor-executable instructions structured as: <ul id="ul0244" list-style="none"><li id="ul0244-0001" num="1507">generate, via at least one processor, a predefined scenario datastructure that includes a simulation identifier associated with the set of simulated market scenarios, identifiers of customized market factors from the set of customized market factors, and the ranges of allowable values for the set of customized market factors.</li></ul></li><li id="ul0129-0319" num="1508">338. The medium of embodiment 321, further, comprising:</li><li id="ul0129-0320" num="1509">the processor-executable instructions structured as: <ul id="ul0245" list-style="none"><li id="ul0245-0001" num="1510">generate, via at least one processor, a predefined scenario datastructure that includes a simulation identifier associated with the set of simulated market scenarios, and identifiers of filtered simulated market scenarios from the set of filtered simulated market scenarios.</li></ul></li><li id="ul0129-0321" num="1511">339. The medium of embodiment 321, further, comprising:</li><li id="ul0129-0322" num="1512">the processor-executable instructions structured as: <ul id="ul0246" list-style="none"><li id="ul0246-0001" num="1513">generate, via at least one processor, a set of factor group filter interaction-interface mechanisms, each factor group filter interaction-interface mechanism in the set of factor group filter interaction-interface mechanisms structured to be associated with a subset of market factor interaction-interface mechanisms from the set of market factor interaction-interface mechanisms.</li></ul></li><li id="ul0129-0323" num="1514">340. The medium of embodiment 339, further, comprising:</li><li id="ul0129-0324" num="1515">the processor-executable instructions structured as: <ul id="ul0247" list-style="none"><li id="ul0247-0001" num="1516">obtain, via at least one processor, a user selection of a factor group filter interaction-interface mechanism in the set of factor group filter interaction-interface mechanisms; and</li><li id="ul0247-0002" num="1517">generate, via at least one processor, a filtered set of market factor interaction-interface mechanisms, each filtered market factor interaction-interface mechanism in the set of filtered market factor interaction-interface mechanisms structured to be associated with the selected factor group filter interaction-interface mechanism.</li></ul></li><li id="ul0129-0325" num="1518">341. A machine learning predefined scenario constructing processor-implemented system, comprising:</li><li id="ul0129-0326" num="1519">means to process processor-executable instructions;</li><li id="ul0129-0327" num="1520">means to issue processor-issuable instructions from a processor-executable component collection via the means to process processor-executable instructions, the processor-issuable instructions structured as: <ul id="ul0248" list-style="none"><li id="ul0248-0001" num="1521">obtain, via at least one processor, a user selection of a set of simulated market scenarios via a simulation selection interaction-interface mechanism, the set of simulated market scenarios generated using a set of deep learning neural networks, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0248-0002" num="1522">determine, via at least one processor, a range of unfiltered simulated market factor values for each market factor from the set of market factors, the range of unfiltered simulated market factor values for a market factor structured to include a minimum simulated market factor value and a maximum simulated market factor value in the set of simulated market scenarios for the respective market factor;</li><li id="ul0248-0003" num="1523">generate, via at least one processor, a set of market factor interaction-interface mechanisms, each market factor interaction-interface mechanism in the set of market factor interaction-interface mechanisms structured to be associated with a market factor from the set of market factors and structured to display the range of unfiltered simulated market factor values for the respective market factor;</li><li id="ul0248-0004" num="1524">obtain, via at least one processor, a user modification to a range of allowable values of a market factor from the set of market factors via the market factor interaction-interface mechanism associated with the modified market factor;</li><li id="ul0248-0005" num="1525">update, via at least one processor, a set of customized market factors from the set of market factors based on the user modification;</li><li id="ul0248-0006" num="1526">determine, via at least one processor, a range of allowable values for each customized market factor from the set of customized market factors;</li><li id="ul0248-0007" num="1527">filter, via at least one processor, the set of simulated market scenarios based on the determined ranges of allowable values for the set of customized market factors to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each customized market factors from the set of customized market factors;</li><li id="ul0248-0008" num="1528">determine, via at least one processor, a range of filtered simulated market factor values for each market factor from the set of market factors, the range of filtered simulated market factor values for a market factor structured to include a minimum simulated market factor value and a maximum simulated market factor value in the set of filtered simulated market scenarios for the respective market factor; and</li><li id="ul0248-0009" num="1529">generate, via at least one processor, an updated set of market factor interaction-interface mechanisms, each updated market factor interaction-interface mechanism in the set of updated market factor interaction-interface mechanisms structured to be associated with a market factor from the set of market factors and structured to display the range of filtered simulated market factor values for the respective market factor.</li></ul></li><li id="ul0129-0328" num="1530">342. The system of embodiment 341, further, comprising:</li><li id="ul0129-0329" num="1531">the instructions to generate the set of simulated market scenarios using the set of deep learning neural networks are structured to comprise instructions to: <ul id="ul0249" list-style="none"><li id="ul0249-0001" num="1532">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0249-0002" num="1533">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0249-0003" num="1534">train, via at least one processor, for each time period bucket from the set of time period buckets, a deep learning neural network, from the set of deep learning neural networks, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0249-0004" num="1535">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained deep learning neural network associated with the respective time period bucket; and</li><li id="ul0249-0005" num="1536">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained deep learning neural network associated with the respective time period bucket.</li></ul></li><li id="ul0129-0330" num="1537">343. The system of embodiment 342, further, comprising:</li><li id="ul0129-0331" num="1538">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0250" list-style="none"><li id="ul0250-0001" num="1539">determine, via at least one processor, a historical data set, a rolling window period length, and the set of market factors;</li><li id="ul0250-0002" num="1540">determine, via at least one processor, a set of rolling window periods using the historical data set and the rolling window period length; and</li><li id="ul0250-0003" num="1541">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0251" list-style="none"><li id="ul0251-0001" num="1542">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0332" num="1543">344. The system of embodiment 343, further, comprising:</li><li id="ul0129-0333" num="1544">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0252" list-style="none"><li id="ul0252-0001" num="1545">determine, via at least one processor, the delta between values of the market factor at a beginning time point and an ending time point of the rolling window period.</li></ul></li><li id="ul0129-0334" num="1546">345. The system of embodiment 344, further, comprising:</li><li id="ul0129-0335" num="1547">the processor-executable instructions structured as: <ul id="ul0253" list-style="none"><li id="ul0253-0001" num="1548">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0253-0002" num="1549">impute, via at least one processor, the unavailable historical data for the time point using a machine learning method.</li></ul></li><li id="ul0129-0336" num="1550">346. The system of embodiment 343, further, comprising:</li><li id="ul0129-0337" num="1551">the rolling window period length is structured to be equal to the time period length.</li><li id="ul0129-0338" num="1552">347. The system of embodiment 342, further, comprising:</li><li id="ul0129-0339" num="1553">the set of time period buckets is structured to have an equal fixed length for each time period bucket.</li><li id="ul0129-0340" num="1554">348. The system of embodiment 342, further, comprising:</li><li id="ul0129-0341" num="1555">the set of time period buckets is structured to have a variable length for each time period bucket, the variable length for each time period bucket determined by judging the overall goodness of fit between the set of simulated market scenarios and the set of historical market scenarios.</li><li id="ul0129-0342" num="1556">349. The system of embodiment 342, further, comprising:</li><li id="ul0129-0343" num="1557">the instructions to train a deep learning neural network for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0254" list-style="none"><li id="ul0254-0001" num="1558">select, via at least one processor, a historical market scenario from the associated subset of historical market scenarios; and</li><li id="ul0254-0002" num="1559">train, via at least one processor, the deep learning neural network for the time period bucket on the selected historical market scenario using a variational autoencoder.</li></ul></li><li id="ul0129-0344" num="1560">350. The system of embodiment 349, further, comprising:</li><li id="ul0129-0345" num="1561">the deep learning neural network for the time period bucket is trained to generate a set of Gaussian mixture latent variables.</li><li id="ul0129-0346" num="1562">351. The system of embodiment 350, further, comprising:</li><li id="ul0129-0347" num="1563">the instructions to generate simulated market scenarios for the time period bucket, using the trained deep learning neural network associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0255" list-style="none"><li id="ul0255-0001" num="1564">generate, via at least one processor, a set of random values for the set of Gaussian mixture latent variables; and</li><li id="ul0255-0002" num="1565">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, from the generated set of random values using a neural network decoder of the trained deep learning neural network associated with the time period bucket.</li></ul></li><li id="ul0129-0348" num="1566">352. The system of embodiment 341, further, comprising:</li><li id="ul0129-0349" num="1567">the simulation selection interaction-interface mechanism is structured to comprise a pricing date selection interaction-interface mechanism and a simulation model selection interaction-interface mechanism.</li><li id="ul0129-0350" num="1568">353. The system of embodiment 341, further, comprising:</li><li id="ul0129-0351" num="1569">the range of unfiltered simulated market factor values for a market factor structured to include an average simulated market factor value in the set of simulated market scenarios for the market factor; and</li><li id="ul0129-0352" num="1570">the range of filtered simulated market factor values for the market factor structured to include an average value in the set of filtered simulated market scenarios for the market factor.</li><li id="ul0129-0353" num="1571">354. The system of embodiment 341, further, comprising:</li><li id="ul0129-0354" num="1572">each market factor interaction-interface mechanism in the set of market factor interaction-interface mechanisms is structured to include a slider interaction-interface mechanism to affect user modification to a range of allowable values of a market factor associated with the respective market factor interaction-interface mechanism.</li><li id="ul0129-0355" num="1573">355. The system of embodiment 341, further, comprising:</li><li id="ul0129-0356" num="1574">the instructions to update the set of customized market factors based on the user modification are structured to comprise instructions to add the modified market factor to the set of customized market factors.</li><li id="ul0129-0357" num="1575">356. The system of embodiment 341, further, comprising:</li><li id="ul0129-0358" num="1576">the instructions to update the set of customized market factors based on the user modification are structured to comprise instructions to remove the modified market factor from the set of customized market factors.</li><li id="ul0129-0359" num="1577">357. The system of embodiment 341, further, comprising:</li><li id="ul0129-0360" num="1578">the processor-executable instructions structured as: <ul id="ul0256" list-style="none"><li id="ul0256-0001" num="1579">generate, via at least one processor, a predefined scenario datastructure that includes a simulation identifier associated with the set of simulated market scenarios, identifiers of customized market factors from the set of customized market factors, and the ranges of allowable values for the set of customized market factors.</li></ul></li><li id="ul0129-0361" num="1580">358. The system of embodiment 341, further, comprising:</li><li id="ul0129-0362" num="1581">the processor-executable instructions structured as: <ul id="ul0257" list-style="none"><li id="ul0257-0001" num="1582">generate, via at least one processor, a predefined scenario datastructure that includes a simulation identifier associated with the set of simulated market scenarios, and identifiers of filtered simulated market scenarios from the set of filtered simulated market scenarios.</li></ul></li><li id="ul0129-0363" num="1583">359. The system of embodiment 341, further, comprising:</li><li id="ul0129-0364" num="1584">the processor-executable instructions structured as: <ul id="ul0258" list-style="none"><li id="ul0258-0001" num="1585">generate, via at least one processor, a set of factor group filter interaction-interface mechanisms, each factor group filter interaction-interface mechanism in the set of factor group filter interaction-interface mechanisms structured to be associated with a subset of market factor interaction-interface mechanisms from the set of market factor interaction-interface mechanisms.</li></ul></li><li id="ul0129-0365" num="1586">360. The system of embodiment 359, further, comprising:</li><li id="ul0129-0366" num="1587">the processor-executable instructions structured as: <ul id="ul0259" list-style="none"><li id="ul0259-0001" num="1588">obtain, via at least one processor, a user selection of a factor group filter interaction-interface mechanism in the set of factor group filter interaction-interface mechanisms; and</li><li id="ul0259-0002" num="1589">generate, via at least one processor, a filtered set of market factor interaction-interface mechanisms, each filtered market factor interaction-interface mechanism in the set of filtered market factor interaction-interface mechanisms structured to be associated with the selected factor group filter interaction-interface mechanism.</li></ul></li><li id="ul0129-0367" num="1590">361. A machine learning predefined scenario constructing processor-implemented process, comprising executing processor-executable instructions to: <ul id="ul0260" list-style="none"><li id="ul0260-0001" num="1591">obtain, via at least one processor, a user selection of a set of simulated market scenarios via a simulation selection interaction-interface mechanism, the set of simulated market scenarios generated using a set of deep learning neural networks, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0260-0002" num="1592">determine, via at least one processor, a range of unfiltered simulated market factor values for each market factor from the set of market factors, the range of unfiltered simulated market factor values for a market factor structured to include a minimum simulated market factor value and a maximum simulated market factor value in the set of simulated market scenarios for the respective market factor;</li><li id="ul0260-0003" num="1593">generate, via at least one processor, a set of market factor interaction-interface mechanisms, each market factor interaction-interface mechanism in the set of market factor interaction-interface mechanisms structured to be associated with a market factor from the set of market factors and structured to display the range of unfiltered simulated market factor values for the respective market factor;</li><li id="ul0260-0004" num="1594">obtain, via at least one processor, a user modification to a range of allowable values of a market factor from the set of market factors via the market factor interaction-interface mechanism associated with the modified market factor;</li><li id="ul0260-0005" num="1595">update, via at least one processor, a set of customized market factors from the set of market factors based on the user modification;</li><li id="ul0260-0006" num="1596">determine, via at least one processor, a range of allowable values for each customized market factor from the set of customized market factors;</li><li id="ul0260-0007" num="1597">filter, via at least one processor, the set of simulated market scenarios based on the determined ranges of allowable values for the set of customized market factors to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each customized market factors from the set of customized market factors;</li><li id="ul0260-0008" num="1598">determine, via at least one processor, a range of filtered simulated market factor values for each market factor from the set of market factors, the range of filtered simulated market factor values for a market factor structured to include a minimum simulated market factor value and a maximum simulated market factor value in the set of filtered simulated market scenarios for the respective market factor; and</li><li id="ul0260-0009" num="1599">generate, via at least one processor, an updated set of market factor interaction-interface mechanisms, each updated market factor interaction-interface mechanism in the set of updated market factor interaction-interface mechanisms structured to be associated with a market factor from the set of market factors and structured to display the range of filtered simulated market factor values for the respective market factor.</li></ul></li><li id="ul0129-0368" num="1600">362. The process of embodiment 361, further, comprising:</li><li id="ul0129-0369" num="1601">the instructions to generate the set of simulated market scenarios using the set of deep learning neural networks are structured to comprise instructions to: <ul id="ul0261" list-style="none"><li id="ul0261-0001" num="1602">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0261-0002" num="1603">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0261-0003" num="1604">train, via at least one processor, for each time period bucket from the set of time period buckets, a deep learning neural network, from the set of deep learning neural networks, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0261-0004" num="1605">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained deep learning neural network associated with the respective time period bucket; and</li><li id="ul0261-0005" num="1606">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained deep learning neural network associated with the respective time period bucket.</li></ul></li><li id="ul0129-0370" num="1607">363. The process of embodiment 362, further, comprising:</li><li id="ul0129-0371" num="1608">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0262" list-style="none"><li id="ul0262-0001" num="1609">determine, via at least one processor, a historical data set, a rolling window period length, and the set of market factors;</li><li id="ul0262-0002" num="1610">determine, via at least one processor, a set of rolling window periods using the historical data set and the rolling window period length; and</li><li id="ul0262-0003" num="1611">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0263" list-style="none"><li id="ul0263-0001" num="1612">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0372" num="1613">364. The process of embodiment 363, further, comprising:</li><li id="ul0129-0373" num="1614">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0264" list-style="none"><li id="ul0264-0001" num="1615">determine, via at least one processor, the delta between values of the market factor at a beginning time point and an ending time point of the rolling window period.</li></ul></li><li id="ul0129-0374" num="1616">365. The process of embodiment 364, further, comprising:</li><li id="ul0129-0375" num="1617">the processor-executable instructions structured as: <ul id="ul0265" list-style="none"><li id="ul0265-0001" num="1618">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0265-0002" num="1619">impute, via at least one processor, the unavailable historical data for the time point using a machine learning method.</li></ul></li><li id="ul0129-0376" num="1620">366. The process of embodiment 363, further, comprising:</li><li id="ul0129-0377" num="1621">the rolling window period length is structured to be equal to the time period length.</li><li id="ul0129-0378" num="1622">367. The process of embodiment 362, further, comprising:</li><li id="ul0129-0379" num="1623">the set of time period buckets is structured to have an equal fixed length for each time period bucket.</li><li id="ul0129-0380" num="1624">368. The process of embodiment 362, further, comprising:</li><li id="ul0129-0381" num="1625">the set of time period buckets is structured to have a variable length for each time period bucket, the variable length for each time period bucket determined by judging the overall goodness of fit between the set of simulated market scenarios and the set of historical market scenarios.</li><li id="ul0129-0382" num="1626">369. The process of embodiment 362, further, comprising:</li><li id="ul0129-0383" num="1627">the instructions to train a deep learning neural network for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0266" list-style="none"><li id="ul0266-0001" num="1628">select, via at least one processor, a historical market scenario from the associated subset of historical market scenarios; and</li><li id="ul0266-0002" num="1629">train, via at least one processor, the deep learning neural network for the time period bucket on the selected historical market scenario using a variational autoencoder.</li></ul></li><li id="ul0129-0384" num="1630">370. The process of embodiment 369, further, comprising:</li><li id="ul0129-0385" num="1631">the deep learning neural network for the time period bucket is trained to generate a set of Gaussian mixture latent variables.</li><li id="ul0129-0386" num="1632">371. The process of embodiment 370, further, comprising:</li><li id="ul0129-0387" num="1633">the instructions to generate simulated market scenarios for the time period bucket, using the trained deep learning neural network associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0267" list-style="none"><li id="ul0267-0001" num="1634">generate, via at least one processor, a set of random values for the set of Gaussian mixture latent variables; and</li><li id="ul0267-0002" num="1635">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, from the generated set of random values using a neural network decoder of the trained deep learning neural network associated with the time period bucket.</li></ul></li><li id="ul0129-0388" num="1636">372. The process of embodiment 361, further, comprising:</li><li id="ul0129-0389" num="1637">the simulation selection interaction-interface mechanism is structured to comprise a pricing date selection interaction-interface mechanism and a simulation model selection interaction-interface mechanism.</li><li id="ul0129-0390" num="1638">373. The process of embodiment 361, further, comprising:</li><li id="ul0129-0391" num="1639">the range of unfiltered simulated market factor values for a market factor structured to include an average simulated market factor value in the set of simulated market scenarios for the market factor; and</li><li id="ul0129-0392" num="1640">the range of filtered simulated market factor values for the market factor structured to include an average value in the set of filtered simulated market scenarios for the market factor.</li><li id="ul0129-0393" num="1641">374. The process of embodiment 361, further, comprising:</li><li id="ul0129-0394" num="1642">each market factor interaction-interface mechanism in the set of market factor interaction-interface mechanisms is structured to include a slider interaction-interface mechanism to affect user modification to a range of allowable values of a market factor associated with the respective market factor interaction-interface mechanism.</li><li id="ul0129-0395" num="1643">375. The process of embodiment 361, further, comprising:</li><li id="ul0129-0396" num="1644">the instructions to update the set of customized market factors based on the user modification are structured to comprise instructions to add the modified market factor to the set of customized market factors.</li><li id="ul0129-0397" num="1645">376. The process of embodiment 361, further, comprising:</li><li id="ul0129-0398" num="1646">the instructions to update the set of customized market factors based on the user modification are structured to comprise instructions to remove the modified market factor from the set of customized market factors.</li><li id="ul0129-0399" num="1647">377. The process of embodiment 361, further, comprising:</li><li id="ul0129-0400" num="1648">the processor-executable instructions structured as: <ul id="ul0268" list-style="none"><li id="ul0268-0001" num="1649">generate, via at least one processor, a predefined scenario datastructure that includes a simulation identifier associated with the set of simulated market scenarios, identifiers of customized market factors from the set of customized market factors, and the ranges of allowable values for the set of customized market factors.</li></ul></li><li id="ul0129-0401" num="1650">378. The process of embodiment 361, further, comprising:</li><li id="ul0129-0402" num="1651">the processor-executable instructions structured as: <ul id="ul0269" list-style="none"><li id="ul0269-0001" num="1652">generate, via at least one processor, a predefined scenario datastructure that includes a simulation identifier associated with the set of simulated market scenarios, and identifiers of filtered simulated market scenarios from the set of filtered simulated market scenarios.</li></ul></li><li id="ul0129-0403" num="1653">379. The process of embodiment 361, further, comprising:</li><li id="ul0129-0404" num="1654">the processor-executable instructions structured as: <ul id="ul0270" list-style="none"><li id="ul0270-0001" num="1655">generate, via at least one processor, a set of factor group filter interaction-interface mechanisms, each factor group filter interaction-interface mechanism in the set of factor group filter interaction-interface mechanisms structured to be associated with a subset of market factor interaction-interface mechanisms from the set of market factor interaction-interface mechanisms.</li></ul></li><li id="ul0129-0405" num="1656">380. The process of embodiment 379, further, comprising:</li><li id="ul0129-0406" num="1657">the processor-executable instructions structured as: <ul id="ul0271" list-style="none"><li id="ul0271-0001" num="1658">obtain, via at least one processor, a user selection of a factor group filter interaction-interface mechanism in the set of factor group filter interaction-interface mechanisms; and</li><li id="ul0271-0002" num="1659">generate, via at least one processor, a filtered set of market factor interaction-interface mechanisms, each filtered market factor interaction-interface mechanism in the set of filtered market factor interaction-interface mechanisms structured to be associated with the selected factor group filter interaction-interface mechanism.</li></ul></li><li id="ul0129-0407" num="1660">401. A machine learning predefined scenario constructing apparatus, comprising:</li><li id="ul0129-0408" num="1661">a memory;</li><li id="ul0129-0409" num="1662">a component collection in the memory;</li><li id="ul0129-0410" num="1663">a processor disposed in communication with the memory and configured to issue a plurality of processor-executable instructions from the component collection, the processor-executable instructions structured as: <ul id="ul0272" list-style="none"><li id="ul0272-0001" num="1664">obtain, via at least one processor, a user selection of a set of simulated market scenarios via a simulation selection interaction-interface mechanism, the set of simulated market scenarios generated using a set of multi-variate mixture datastructures, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0272-0002" num="1665">determine, via at least one processor, a range of unfiltered simulated market factor values for each market factor from the set of market factors, the range of unfiltered simulated market factor values for a market factor structured to include a minimum simulated market factor value and a maximum simulated market factor value in the set of simulated market scenarios for the respective market factor;</li><li id="ul0272-0003" num="1666">generate, via at least one processor, a set of market factor interaction-interface mechanisms, each market factor interaction-interface mechanism in the set of market factor interaction-interface mechanisms structured to be associated with a market factor from the set of market factors and structured to display the range of unfiltered simulated market factor values for the respective market factor;</li><li id="ul0272-0004" num="1667">obtain, via at least one processor, a user modification to a range of allowable values of a market factor from the set of market factors via the market factor interaction-interface mechanism associated with the modified market factor;</li><li id="ul0272-0005" num="1668">update, via at least one processor, a set of customized market factors from the set of market factors based on the user modification;</li><li id="ul0272-0006" num="1669">determine, via at least one processor, a range of allowable values for each customized market factor from the set of customized market factors;</li><li id="ul0272-0007" num="1670">filter, via at least one processor, the set of simulated market scenarios based on the determined ranges of allowable values for the set of customized market factors to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each customized market factors from the set of customized market factors;</li><li id="ul0272-0008" num="1671">determine, via at least one processor, a range of filtered simulated market factor values for each market factor from the set of market factors, the range of filtered simulated market factor values for a market factor structured to include a minimum simulated market factor value and a maximum simulated market factor value in the set of filtered simulated market scenarios for the respective market factor; and</li><li id="ul0272-0009" num="1672">generate, via at least one processor, an updated set of market factor interaction-interface mechanisms, each updated market factor interaction-interface mechanism in the set of updated market factor interaction-interface mechanisms structured to be associated with a market factor from the set of market factors and structured to display the range of filtered simulated market factor values for the respective market factor.</li></ul></li><li id="ul0129-0411" num="1673">402. The apparatus of embodiment 401, further, comprising:</li><li id="ul0129-0412" num="1674">the instructions to generate the set of simulated market scenarios using the set of multi-variate mixture datastructures are structured to comprise instructions to <ul id="ul0273" list-style="none"><li id="ul0273-0001" num="1675">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0273-0002" num="1676">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0273-0003" num="1677">train, via at least one processor, for each time period bucket from the set of time period buckets, a multi-variate mixture datastructure, from the set of multi-variate mixture datastructures, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0273-0004" num="1678">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained multi-variate mixture datastructure associated with the respective time period bucket; and</li><li id="ul0273-0005" num="1679">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained multi-variate mixture datastructures associated with the respective time period bucket.</li></ul></li><li id="ul0129-0413" num="1680">403. The apparatus of embodiment 402, further, comprising:</li><li id="ul0129-0414" num="1681">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0274" list-style="none"><li id="ul0274-0001" num="1682">determine, via at least one processor, a historical data set and the set of market factors;</li><li id="ul0274-0002" num="1683">determine, via at least one processor, a set of rolling window periods for the historical data set; and</li><li id="ul0274-0003" num="1684">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0275" list-style="none"><li id="ul0275-0001" num="1685">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0415" num="1686">404. The apparatus of embodiment 403, further, comprising:</li><li id="ul0129-0416" num="1687">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0276" list-style="none"><li id="ul0276-0001" num="1688">determine, via at least one processor, the delta between values of the market factor at two time point of the rolling window period.</li></ul></li><li id="ul0129-0417" num="1689">405. The apparatus of embodiment 404, further, comprising:</li><li id="ul0129-0418" num="1690">the processor-executable instructions structured as: <ul id="ul0277" list-style="none"><li id="ul0277-0001" num="1691">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0277-0002" num="1692">impute, via at least one processor, the unavailable historical data for the time point using a k-Nearest Neighbors method.</li></ul></li><li id="ul0129-0419" num="1693">406. The apparatus of embodiment 403, further, comprising:</li><li id="ul0129-0420" num="1694">the length of a rolling window period is structured to be equal to the time period length.</li><li id="ul0129-0421" num="1695">407. The apparatus of embodiment 402, further, comprising:</li><li id="ul0129-0422" num="1696">the set of time period buckets is structured to have a fixed length for each time period bucket.</li><li id="ul0129-0423" num="1697">408. The apparatus of embodiment 402, further, comprising:</li><li id="ul0129-0424" num="1698">the set of time period buckets is structured to have variable lengths, the variable length for each time period bucket reflective of changes in volatilities and correlations of the set of historical market scenarios.</li><li id="ul0129-0425" num="1699">409. The apparatus of embodiment 403, further, comprising:</li><li id="ul0129-0426" num="1700">the instructions to train a multi-variate mixture datastructure for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0278" list-style="none"><li id="ul0278-0001" num="1701">determine, via at least one processor, for each market factor from the set of market factors, a distribution to use for the respective market factor for the time period bucket;</li><li id="ul0278-0002" num="1702">fit, via at least one processor, for each market factor from the set of market factors, the distribution to use for the respective market factor for the time period bucket using the associated subset of historical market scenarios;</li><li id="ul0278-0003" num="1703">determine, via at least one processor, a copula for the set of market factors for the time period bucket; and</li><li id="ul0278-0004" num="1704">train, via at least one processor, the multi-variate mixture datastructure for the time period bucket using the fitted distributions and the copula for the set of market factors.</li></ul></li><li id="ul0129-0427" num="1705">410. The apparatus of embodiment 409, further, comprising:</li><li id="ul0129-0428" num="1706">the instructions to fit the distribution to use for a market factor for the time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to calculate the mean of the market factor's values in the associated subset of historical market scenarios.</li><li id="ul0129-0429" num="1707">411. The apparatus of embodiment 402, further, comprising:</li><li id="ul0129-0430" num="1708">the instructions to generate simulated market scenarios for a time period bucket, using the trained multi-variate mixture datastructure associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0279" list-style="none"><li id="ul0279-0001" num="1709">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, by sampling the trained multi-variate mixture datastructure associated with the time period bucket.</li></ul></li><li id="ul0129-0431" num="1710">412. The apparatus of embodiment 401, further, comprising:</li><li id="ul0129-0432" num="1711">the simulation selection interaction-interface mechanism is structured to comprise a pricing date selection interaction-interface mechanism and a simulation model selection interaction-interface mechanism.</li><li id="ul0129-0433" num="1712">413. The apparatus of embodiment 401, further, comprising:</li><li id="ul0129-0434" num="1713">the range of unfiltered simulated market factor values for a market factor structured to include an average simulated market factor value in the set of simulated market scenarios for the market factor; and</li><li id="ul0129-0435" num="1714">the range of filtered simulated market factor values for the market factor structured to include an average value in the set of filtered simulated market scenarios for the market factor.</li><li id="ul0129-0436" num="1715">414. The apparatus of embodiment 401, further, comprising:</li><li id="ul0129-0437" num="1716">each market factor interaction-interface mechanism in the set of market factor interaction-interface mechanisms is structured to include a slider interaction-interface mechanism to affect user modification to a range of allowable values of a market factor associated with the respective market factor interaction-interface mechanism.</li><li id="ul0129-0438" num="1717">415. The apparatus of embodiment 401, further, comprising:</li><li id="ul0129-0439" num="1718">the instructions to update the set of customized market factors based on the user modification are structured to comprise instructions to add the modified market factor to the set of customized market factors.</li><li id="ul0129-0440" num="1719">416. The apparatus of embodiment 401, further, comprising:</li><li id="ul0129-0441" num="1720">the instructions to update the set of customized market factors based on the user modification are structured to comprise instructions to remove the modified market factor from the set of customized market factors.</li><li id="ul0129-0442" num="1721">417. The apparatus of embodiment 401, further, comprising:</li><li id="ul0129-0443" num="1722">the processor-executable instructions structured as: <ul id="ul0280" list-style="none"><li id="ul0280-0001" num="1723">generate, via at least one processor, a predefined scenario datastructure that includes a simulation identifier associated with the set of simulated market scenarios, identifiers of customized market factors from the set of customized market factors, and the ranges of allowable values for the set of customized market factors.</li></ul></li><li id="ul0129-0444" num="1724">418. The apparatus of embodiment 401, further, comprising:</li><li id="ul0129-0445" num="1725">the processor-executable instructions structured as: <ul id="ul0281" list-style="none"><li id="ul0281-0001" num="1726">generate, via at least one processor, a predefined scenario datastructure that includes a simulation identifier associated with the set of simulated market scenarios, and identifiers of filtered simulated market scenarios from the set of filtered simulated market scenarios.</li></ul></li><li id="ul0129-0446" num="1727">419. The apparatus of embodiment 401, further, comprising:</li><li id="ul0129-0447" num="1728">the processor-executable instructions structured as: <ul id="ul0282" list-style="none"><li id="ul0282-0001" num="1729">generate, via at least one processor, a set of factor group filter interaction-interface mechanisms, each factor group filter interaction-interface mechanism in the set of factor group filter interaction-interface mechanisms structured to be associated with a subset of market factor interaction-interface mechanisms from the set of market factor interaction-interface mechanisms.</li></ul></li><li id="ul0129-0448" num="1730">420. The apparatus of embodiment 419, further, comprising:</li><li id="ul0129-0449" num="1731">the processor-executable instructions structured as: <ul id="ul0283" list-style="none"><li id="ul0283-0001" num="1732">obtain, via at least one processor, a user selection of a factor group filter interaction-interface mechanism in the set of factor group filter interaction-interface mechanisms; and</li><li id="ul0283-0002" num="1733">generate, via at least one processor, a filtered set of market factor interaction-interface mechanisms, each filtered market factor interaction-interface mechanism in the set of filtered market factor interaction-interface mechanisms structured to be associated with the selected factor group filter interaction-interface mechanism.</li></ul></li><li id="ul0129-0450" num="1734">421. A machine learning predefined scenario constructing processor-readable, non-transient medium, comprising processor-executable instructions structured as: <ul id="ul0284" list-style="none"><li id="ul0284-0001" num="1735">obtain, via at least one processor, a user selection of a set of simulated market scenarios via a simulation selection interaction-interface mechanism, the set of simulated market scenarios generated using a set of multi-variate mixture datastructures, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0284-0002" num="1736">determine, via at least one processor, a range of unfiltered simulated market factor values for each market factor from the set of market factors, the range of unfiltered simulated market factor values for a market factor structured to include a minimum simulated market factor value and a maximum simulated market factor value in the set of simulated market scenarios for the respective market factor;</li><li id="ul0284-0003" num="1737">generate, via at least one processor, a set of market factor interaction-interface mechanisms, each market factor interaction-interface mechanism in the set of market factor interaction-interface mechanisms structured to be associated with a market factor from the set of market factors and structured to display the range of unfiltered simulated market factor values for the respective market factor;</li><li id="ul0284-0004" num="1738">obtain, via at least one processor, a user modification to a range of allowable values of a market factor from the set of market factors via the market factor interaction-interface mechanism associated with the modified market factor;</li><li id="ul0284-0005" num="1739">update, via at least one processor, a set of customized market factors from the set of market factors based on the user modification;</li><li id="ul0284-0006" num="1740">determine, via at least one processor, a range of allowable values for each customized market factor from the set of customized market factors;</li><li id="ul0284-0007" num="1741">filter, via at least one processor, the set of simulated market scenarios based on the determined ranges of allowable values for the set of customized market factors to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each customized market factors from the set of customized market factors;</li><li id="ul0284-0008" num="1742">determine, via at least one processor, a range of filtered simulated market factor values for each market factor from the set of market factors, the range of filtered simulated market factor values for a market factor structured to include a minimum simulated market factor value and a maximum simulated market factor value in the set of filtered simulated market scenarios for the respective market factor; and</li><li id="ul0284-0009" num="1743">generate, via at least one processor, an updated set of market factor interaction-interface mechanisms, each updated market factor interaction-interface mechanism in the set of updated market factor interaction-interface mechanisms structured to be associated with a market factor from the set of market factors and structured to display the range of filtered simulated market factor values for the respective market factor.</li></ul></li><li id="ul0129-0451" num="1744">422. The medium of embodiment 421, further, comprising:</li><li id="ul0129-0452" num="1745">the instructions to generate the set of simulated market scenarios using the set of multi-variate mixture datastructures are structured to comprise instructions to <ul id="ul0285" list-style="none"><li id="ul0285-0001" num="1746">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0285-0002" num="1747">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0285-0003" num="1748">train, via at least one processor, for each time period bucket from the set of time period buckets, a multi-variate mixture datastructure, from the set of multi-variate mixture datastructures, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0285-0004" num="1749">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained multi-variate mixture datastructure associated with the respective time period bucket; and</li><li id="ul0285-0005" num="1750">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained multi-variate mixture datastructures associated with the respective time period bucket.</li></ul></li><li id="ul0129-0453" num="1751">423. The medium of embodiment 422, further, comprising:</li><li id="ul0129-0454" num="1752">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0286" list-style="none"><li id="ul0286-0001" num="1753">determine, via at least one processor, a historical data set and the set of market factors;</li><li id="ul0286-0002" num="1754">determine, via at least one processor, a set of rolling window periods for the historical data set; and</li><li id="ul0286-0003" num="1755">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0287" list-style="none"><li id="ul0287-0001" num="1756">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0455" num="1757">424. The medium of embodiment 423, further, comprising:</li><li id="ul0129-0456" num="1758">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0288" list-style="none"><li id="ul0288-0001" num="1759">determine, via at least one processor, the delta between values of the market factor at two time point of the rolling window period.</li></ul></li><li id="ul0129-0457" num="1760">425. The medium of embodiment 424, further, comprising:</li><li id="ul0129-0458" num="1761">the processor-executable instructions structured as: <ul id="ul0289" list-style="none"><li id="ul0289-0001" num="1762">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0289-0002" num="1763">impute, via at least one processor, the unavailable historical data for the time point using a k-Nearest Neighbors method.</li></ul></li><li id="ul0129-0459" num="1764">426. The medium of embodiment 423, further, comprising:</li><li id="ul0129-0460" num="1765">the length of a rolling window period is structured to be equal to the time period length.</li><li id="ul0129-0461" num="1766">427. The medium of embodiment 422, further, comprising:</li><li id="ul0129-0462" num="1767">the set of time period buckets is structured to have a fixed length for each time period bucket.</li><li id="ul0129-0463" num="1768">428. The medium of embodiment 422, further, comprising:</li><li id="ul0129-0464" num="1769">the set of time period buckets is structured to have variable lengths, the variable length for each time period bucket reflective of changes in volatilities and correlations of the set of historical market scenarios.</li><li id="ul0129-0465" num="1770">429. The medium of embodiment 423, further, comprising:</li><li id="ul0129-0466" num="1771">the instructions to train a multi-variate mixture datastructure for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0290" list-style="none"><li id="ul0290-0001" num="1772">determine, via at least one processor, for each market factor from the set of market factors, a distribution to use for the respective market factor for the time period bucket;</li><li id="ul0290-0002" num="1773">fit, via at least one processor, for each market factor from the set of market factors, the distribution to use for the respective market factor for the time period bucket using the associated subset of historical market scenarios;</li><li id="ul0290-0003" num="1774">determine, via at least one processor, a copula for the set of market factors for the time period bucket; and</li><li id="ul0290-0004" num="1775">train, via at least one processor, the multi-variate mixture datastructure for the time period bucket using the fitted distributions and the copula for the set of market factors.</li></ul></li><li id="ul0129-0467" num="1776">430. The medium of embodiment 429, further, comprising:</li><li id="ul0129-0468" num="1777">the instructions to fit the distribution to use for a market factor for the time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to calculate the mean of the market factor's values in the associated subset of historical market scenarios.</li><li id="ul0129-0469" num="1778">431. The medium of embodiment 422, further, comprising:</li><li id="ul0129-0470" num="1779">the instructions to generate simulated market scenarios for a time period bucket, using the trained multi-variate mixture datastructure associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0291" list-style="none"><li id="ul0291-0001" num="1780">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, by sampling the trained multi-variate mixture datastructure associated with the time period bucket.</li></ul></li><li id="ul0129-0471" num="1781">432. The medium of embodiment 421, further, comprising:</li><li id="ul0129-0472" num="1782">the simulation selection interaction-interface mechanism is structured to comprise a pricing date selection interaction-interface mechanism and a simulation model selection interaction-interface mechanism.</li><li id="ul0129-0473" num="1783">433. The medium of embodiment 421, further, comprising:</li><li id="ul0129-0474" num="1784">the range of unfiltered simulated market factor values for a market factor structured to include an average simulated market factor value in the set of simulated market scenarios for the market factor; and</li><li id="ul0129-0475" num="1785">the range of filtered simulated market factor values for the market factor structured to include an average value in the set of filtered simulated market scenarios for the market factor.</li><li id="ul0129-0476" num="1786">434. The medium of embodiment 421, further, comprising:</li><li id="ul0129-0477" num="1787">each market factor interaction-interface mechanism in the set of market factor interaction-interface mechanisms is structured to include a slider interaction-interface mechanism to affect user modification to a range of allowable values of a market factor associated with the respective market factor interaction-interface mechanism.</li><li id="ul0129-0478" num="1788">435. The medium of embodiment 421, further, comprising:</li><li id="ul0129-0479" num="1789">the instructions to update the set of customized market factors based on the user modification are structured to comprise instructions to add the modified market factor to the set of customized market factors.</li><li id="ul0129-0480" num="1790">436. The medium of embodiment 421, further, comprising:</li><li id="ul0129-0481" num="1791">the instructions to update the set of customized market factors based on the user modification are structured to comprise instructions to remove the modified market factor from the set of customized market factors.</li><li id="ul0129-0482" num="1792">437. The medium of embodiment 421, further, comprising:</li><li id="ul0129-0483" num="1793">the processor-executable instructions structured as: <ul id="ul0292" list-style="none"><li id="ul0292-0001" num="1794">generate, via at least one processor, a predefined scenario datastructure that includes a simulation identifier associated with the set of simulated market scenarios, identifiers of customized market factors from the set of customized market factors, and the ranges of allowable values for the set of customized market factors.</li></ul></li><li id="ul0129-0484" num="1795">438. The medium of embodiment 421, further, comprising:</li><li id="ul0129-0485" num="1796">the processor-executable instructions structured as: <ul id="ul0293" list-style="none"><li id="ul0293-0001" num="1797">generate, via at least one processor, a predefined scenario datastructure that includes a simulation identifier associated with the set of simulated market scenarios, and identifiers of filtered simulated market scenarios from the set of filtered simulated market scenarios.</li></ul></li><li id="ul0129-0486" num="1798">439. The medium of embodiment 421, further, comprising:</li><li id="ul0129-0487" num="1799">the processor-executable instructions structured as: <ul id="ul0294" list-style="none"><li id="ul0294-0001" num="1800">generate, via at least one processor, a set of factor group filter interaction-interface mechanisms, each factor group filter interaction-interface mechanism in the set of factor group filter interaction-interface mechanisms structured to be associated with a subset of market factor interaction-interface mechanisms from the set of market factor interaction-interface mechanisms.</li></ul></li><li id="ul0129-0488" num="1801">440. The medium of embodiment 439, further, comprising:</li><li id="ul0129-0489" num="1802">the processor-executable instructions structured as: <ul id="ul0295" list-style="none"><li id="ul0295-0001" num="1803">obtain, via at least one processor, a user selection of a factor group filter interaction-interface mechanism in the set of factor group filter interaction-interface mechanisms; and</li><li id="ul0295-0002" num="1804">generate, via at least one processor, a filtered set of market factor interaction-interface mechanisms, each filtered market factor interaction-interface mechanism in the set of filtered market factor interaction-interface mechanisms structured to be associated with the selected factor group filter interaction-interface mechanism.</li></ul></li><li id="ul0129-0490" num="1805">441. A machine learning predefined scenario constructing processor-implemented system, comprising:</li><li id="ul0129-0491" num="1806">means to process processor-executable instructions; <ul id="ul0296" list-style="none"><li id="ul0296-0001" num="1807">means to issue processor-issuable instructions from a processor-executable component collection via the means to process processor-executable instructions, the processor-issuable instructions structured as:</li><li id="ul0296-0002" num="1808">obtain, via at least one processor, a user selection of a set of simulated market scenarios via a simulation selection interaction-interface mechanism, the set of simulated market scenarios generated using a set of multi-variate mixture datastructures, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0296-0003" num="1809">determine, via at least one processor, a range of unfiltered simulated market factor values for each market factor from the set of market factors, the range of unfiltered simulated market factor values for a market factor structured to include a minimum simulated market factor value and a maximum simulated market factor value in the set of simulated market scenarios for the respective market factor;</li><li id="ul0296-0004" num="1810">generate, via at least one processor, a set of market factor interaction-interface mechanisms, each market factor interaction-interface mechanism in the set of market factor interaction-interface mechanisms structured to be associated with a market factor from the set of market factors and structured to display the range of unfiltered simulated market factor values for the respective market factor;</li><li id="ul0296-0005" num="1811">obtain, via at least one processor, a user modification to a range of allowable values of a market factor from the set of market factors via the market factor interaction-interface mechanism associated with the modified market factor;</li><li id="ul0296-0006" num="1812">update, via at least one processor, a set of customized market factors from the set of market factors based on the user modification;</li><li id="ul0296-0007" num="1813">determine, via at least one processor, a range of allowable values for each customized market factor from the set of customized market factors;</li><li id="ul0296-0008" num="1814">filter, via at least one processor, the set of simulated market scenarios based on the determined ranges of allowable values for the set of customized market factors to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each customized market factors from the set of customized market factors;</li><li id="ul0296-0009" num="1815">determine, via at least one processor, a range of filtered simulated market factor values for each market factor from the set of market factors, the range of filtered simulated market factor values for a market factor structured to include a minimum simulated market factor value and a maximum simulated market factor value in the set of filtered simulated market scenarios for the respective market factor; and</li><li id="ul0296-0010" num="1816">generate, via at least one processor, an updated set of market factor interaction-interface mechanisms, each updated market factor interaction-interface mechanism in the set of updated market factor interaction-interface mechanisms structured to be associated with a market factor from the set of market factors and structured to display the range of filtered simulated market factor values for the respective market factor.</li></ul></li><li id="ul0129-0492" num="1817">442. The system of embodiment 441, further, comprising:</li><li id="ul0129-0493" num="1818">the instructions to generate the set of simulated market scenarios using the set of multi-variate mixture datastructures are structured to comprise instructions to <ul id="ul0297" list-style="none"><li id="ul0297-0001" num="1819">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0297-0002" num="1820">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0297-0003" num="1821">train, via at least one processor, for each time period bucket from the set of time period buckets, a multi-variate mixture datastructure, from the set of multi-variate mixture datastructures, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0297-0004" num="1822">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained multi-variate mixture datastructure associated with the respective time period bucket; and</li><li id="ul0297-0005" num="1823">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained multi-variate mixture datastructures associated with the respective time period bucket.</li></ul></li><li id="ul0129-0494" num="1824">443. The system of embodiment 442, further, comprising:</li><li id="ul0129-0495" num="1825">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0298" list-style="none"><li id="ul0298-0001" num="1826">determine, via at least one processor, a historical data set and the set of market factors;</li><li id="ul0298-0002" num="1827">determine, via at least one processor, a set of rolling window periods for the historical data set; and</li><li id="ul0298-0003" num="1828">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0299" list-style="none"><li id="ul0299-0001" num="1829">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0496" num="1830">444. The system of embodiment 443, further, comprising:</li><li id="ul0129-0497" num="1831">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0300" list-style="none"><li id="ul0300-0001" num="1832">determine, via at least one processor, the delta between values of the market factor at two time point of the rolling window period.</li></ul></li><li id="ul0129-0498" num="1833">445. The system of embodiment 444, further, comprising:</li><li id="ul0129-0499" num="1834">the processor-executable instructions structured as: <ul id="ul0301" list-style="none"><li id="ul0301-0001" num="1835">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0301-0002" num="1836">impute, via at least one processor, the unavailable historical data for the time point using a k-Nearest Neighbors method.</li></ul></li><li id="ul0129-0500" num="1837">446. The system of embodiment 443, further, comprising:</li><li id="ul0129-0501" num="1838">the length of a rolling window period is structured to be equal to the time period length.</li><li id="ul0129-0502" num="1839">447. The system of embodiment 442, further, comprising:</li><li id="ul0129-0503" num="1840">the set of time period buckets is structured to have a fixed length for each time period bucket.</li><li id="ul0129-0504" num="1841">448. The system of embodiment 442, further, comprising:</li><li id="ul0129-0505" num="1842">the set of time period buckets is structured to have variable lengths, the variable length for each time period bucket reflective of changes in volatilities and correlations of the set of historical market scenarios.</li><li id="ul0129-0506" num="1843">449. The system of embodiment 443, further, comprising:</li><li id="ul0129-0507" num="1844">the instructions to train a multi-variate mixture datastructure for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0302" list-style="none"><li id="ul0302-0001" num="1845">determine, via at least one processor, for each market factor from the set of market factors, a distribution to use for the respective market factor for the time period bucket;</li><li id="ul0302-0002" num="1846">fit, via at least one processor, for each market factor from the set of market factors, the distribution to use for the respective market factor for the time period bucket using the associated subset of historical market scenarios;</li><li id="ul0302-0003" num="1847">determine, via at least one processor, a copula for the set of market factors for the time period bucket; and</li><li id="ul0302-0004" num="1848">train, via at least one processor, the multi-variate mixture datastructure for the time period bucket using the fitted distributions and the copula for the set of market factors.</li></ul></li><li id="ul0129-0508" num="1849">450. The system of embodiment 449, further, comprising:</li><li id="ul0129-0509" num="1850">the instructions to fit the distribution to use for a market factor for the time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to calculate the mean of the market factor's values in the associated subset of historical market scenarios.</li><li id="ul0129-0510" num="1851">451. The system of embodiment 442, further, comprising:</li><li id="ul0129-0511" num="1852">the instructions to generate simulated market scenarios for a time period bucket, using the trained multi-variate mixture datastructure associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0303" list-style="none"><li id="ul0303-0001" num="1853">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, by sampling the trained multi-variate mixture datastructure associated with the time period bucket.</li></ul></li><li id="ul0129-0512" num="1854">452. The system of embodiment 441, further, comprising:</li><li id="ul0129-0513" num="1855">the simulation selection interaction-interface mechanism is structured to comprise a pricing date selection interaction-interface mechanism and a simulation model selection interaction-interface mechanism.</li><li id="ul0129-0514" num="1856">453. The system of embodiment 441, further, comprising:</li><li id="ul0129-0515" num="1857">the range of unfiltered simulated market factor values for a market factor structured to include an average simulated market factor value in the set of simulated market scenarios for the market factor; and</li><li id="ul0129-0516" num="1858">the range of filtered simulated market factor values for the market factor structured to include an average value in the set of filtered simulated market scenarios for the market factor.</li><li id="ul0129-0517" num="1859">454. The system of embodiment 441, further, comprising:</li><li id="ul0129-0518" num="1860">each market factor interaction-interface mechanism in the set of market factor interaction-interface mechanisms is structured to include a slider interaction-interface mechanism to affect user modification to a range of allowable values of a market factor associated with the respective market factor interaction-interface mechanism.</li><li id="ul0129-0519" num="1861">455. The system of embodiment 441, further, comprising:</li><li id="ul0129-0520" num="1862">the instructions to update the set of customized market factors based on the user modification are structured to comprise instructions to add the modified market factor to the set of customized market factors.</li><li id="ul0129-0521" num="1863">456. The system of embodiment 441, further, comprising:</li><li id="ul0129-0522" num="1864">the instructions to update the set of customized market factors based on the user modification are structured to comprise instructions to remove the modified market factor from the set of customized market factors.</li><li id="ul0129-0523" num="1865">457. The system of embodiment 441, further, comprising:</li><li id="ul0129-0524" num="1866">the processor-executable instructions structured as: <ul id="ul0304" list-style="none"><li id="ul0304-0001" num="1867">generate, via at least one processor, a predefined scenario datastructure that includes a simulation identifier associated with the set of simulated market scenarios, identifiers of customized market factors from the set of customized market factors, and the ranges of allowable values for the set of customized market factors.</li></ul></li><li id="ul0129-0525" num="1868">458. The system of embodiment 441, further, comprising:</li><li id="ul0129-0526" num="1869">the processor-executable instructions structured as: <ul id="ul0305" list-style="none"><li id="ul0305-0001" num="1870">generate, via at least one processor, a predefined scenario datastructure that includes a simulation identifier associated with the set of simulated market scenarios, and identifiers of filtered simulated market scenarios from the set of filtered simulated market scenarios.</li></ul></li><li id="ul0129-0527" num="1871">459. The system of embodiment 441, further, comprising:</li><li id="ul0129-0528" num="1872">the processor-executable instructions structured as: <ul id="ul0306" list-style="none"><li id="ul0306-0001" num="1873">generate, via at least one processor, a set of factor group filter interaction-interface mechanisms, each factor group filter interaction-interface mechanism in the set of factor group filter interaction-interface mechanisms structured to be associated with a subset of market factor interaction-interface mechanisms from the set of market factor interaction-interface mechanisms.</li></ul></li><li id="ul0129-0529" num="1874">460. The system of embodiment 459, further, comprising:</li><li id="ul0129-0530" num="1875">the processor-executable instructions structured as: <ul id="ul0307" list-style="none"><li id="ul0307-0001" num="1876">obtain, via at least one processor, a user selection of a factor group filter interaction-interface mechanism in the set of factor group filter interaction-interface mechanisms; and</li><li id="ul0307-0002" num="1877">generate, via at least one processor, a filtered set of market factor interaction-interface mechanisms, each filtered market factor interaction-interface mechanism in the set of filtered market factor interaction-interface mechanisms structured to be associated with the selected factor group filter interaction-interface mechanism.</li></ul></li><li id="ul0129-0531" num="1878">461. A machine learning predefined scenario constructing processor-implemented process, comprising executing processor-executable instructions to: <ul id="ul0308" list-style="none"><li id="ul0308-0001" num="1879">obtain, via at least one processor, a user selection of a set of simulated market scenarios via a simulation selection interaction-interface mechanism, the set of simulated market scenarios generated using a set of multi-variate mixture datastructures, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0308-0002" num="1880">determine, via at least one processor, a range of unfiltered simulated market factor values for each market factor from the set of market factors, the range of unfiltered simulated market factor values for a market factor structured to include a minimum simulated market factor value and a maximum simulated market factor value in the set of simulated market scenarios for the respective market factor;</li><li id="ul0308-0003" num="1881">generate, via at least one processor, a set of market factor interaction-interface mechanisms, each market factor interaction-interface mechanism in the set of market factor interaction-interface mechanisms structured to be associated with a market factor from the set of market factors and structured to display the range of unfiltered simulated market factor values for the respective market factor;</li><li id="ul0308-0004" num="1882">obtain, via at least one processor, a user modification to a range of allowable values of a market factor from the set of market factors via the market factor interaction-interface mechanism associated with the modified market factor;</li><li id="ul0308-0005" num="1883">update, via at least one processor, a set of customized market factors from the set of market factors based on the user modification;</li><li id="ul0308-0006" num="1884">determine, via at least one processor, a range of allowable values for each customized market factor from the set of customized market factors;</li><li id="ul0308-0007" num="1885">filter, via at least one processor, the set of simulated market scenarios based on the determined ranges of allowable values for the set of customized market factors to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each customized market factors from the set of customized market factors;</li><li id="ul0308-0008" num="1886">determine, via at least one processor, a range of filtered simulated market factor values for each market factor from the set of market factors, the range of filtered simulated market factor values for a market factor structured to include a minimum simulated market factor value and a maximum simulated market factor value in the set of filtered simulated market scenarios for the respective market factor; and</li><li id="ul0308-0009" num="1887">generate, via at least one processor, an updated set of market factor interaction-interface mechanisms, each updated market factor interaction-interface mechanism in the set of updated market factor interaction-interface mechanisms structured to be associated with a market factor from the set of market factors and structured to display the range of filtered simulated market factor values for the respective market factor.</li></ul></li><li id="ul0129-0532" num="1888">462. The process of embodiment 461, further, comprising:</li><li id="ul0129-0533" num="1889">the instructions to generate the set of simulated market scenarios using the set of multi-variate mixture datastructures are structured to comprise instructions to <ul id="ul0309" list-style="none"><li id="ul0309-0001" num="1890">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0309-0002" num="1891">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0309-0003" num="1892">train, via at least one processor, for each time period bucket from the set of time period buckets, a multi-variate mixture datastructure, from the set of multi-variate mixture datastructures, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0309-0004" num="1893">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained multi-variate mixture datastructure associated with the respective time period bucket; and</li><li id="ul0309-0005" num="1894">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained multi-variate mixture datastructures associated with the respective time period bucket.</li></ul></li><li id="ul0129-0534" num="1895">463. The process of embodiment 462, further, comprising:</li><li id="ul0129-0535" num="1896">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0310" list-style="none"><li id="ul0310-0001" num="1897">determine, via at least one processor, a historical data set and the set of market factors;</li><li id="ul0310-0002" num="1898">determine, via at least one processor, a set of rolling window periods for the historical data set; and</li><li id="ul0310-0003" num="1899">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0311" list-style="none"><li id="ul0311-0001" num="1900">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0536" num="1901">464. The process of embodiment 463, further, comprising:</li><li id="ul0129-0537" num="1902">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0312" list-style="none"><li id="ul0312-0001" num="1903">determine, via at least one processor, the delta between values of the market factor at two time point of the rolling window period.</li></ul></li><li id="ul0129-0538" num="1904">465. The process of embodiment 464, further, comprising:</li><li id="ul0129-0539" num="1905">the processor-executable instructions structured as: <ul id="ul0313" list-style="none"><li id="ul0313-0001" num="1906">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0313-0002" num="1907">impute, via at least one processor, the unavailable historical data for the time point using a k-Nearest Neighbors method.</li></ul></li><li id="ul0129-0540" num="1908">466. The process of embodiment 463, further, comprising:</li><li id="ul0129-0541" num="1909">the length of a rolling window period is structured to be equal to the time period length.</li><li id="ul0129-0542" num="1910">467. The process of embodiment 462, further, comprising:</li><li id="ul0129-0543" num="1911">the set of time period buckets is structured to have a fixed length for each time period bucket.</li><li id="ul0129-0544" num="1912">468. The process of embodiment 462, further, comprising:</li><li id="ul0129-0545" num="1913">the set of time period buckets is structured to have variable lengths, the variable length for each time period bucket reflective of changes in volatilities and correlations of the set of historical market scenarios.</li><li id="ul0129-0546" num="1914">469. The process of embodiment 463, further, comprising:</li><li id="ul0129-0547" num="1915">the instructions to train a multi-variate mixture datastructure for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0314" list-style="none"><li id="ul0314-0001" num="1916">determine, via at least one processor, for each market factor from the set of market factors, a distribution to use for the respective market factor for the time period bucket;</li><li id="ul0314-0002" num="1917">fit, via at least one processor, for each market factor from the set of market factors, the distribution to use for the respective market factor for the time period bucket using the associated subset of historical market scenarios;</li><li id="ul0314-0003" num="1918">determine, via at least one processor, a copula for the set of market factors for the time period bucket; and</li><li id="ul0314-0004" num="1919">train, via at least one processor, the multi-variate mixture datastructure for the time period bucket using the fitted distributions and the copula for the set of market factors.</li></ul></li><li id="ul0129-0548" num="1920">470. The process of embodiment 469, further, comprising:</li><li id="ul0129-0549" num="1921">the instructions to fit the distribution to use for a market factor for the time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to calculate the mean of the market factor's values in the associated subset of historical market scenarios.</li><li id="ul0129-0550" num="1922">471. The process of embodiment 462, further, comprising:</li><li id="ul0129-0551" num="1923">the instructions to generate simulated market scenarios for a time period bucket, using the trained multi-variate mixture datastructure associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0315" list-style="none"><li id="ul0315-0001" num="1924">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, by sampling the trained multi-variate mixture datastructure associated with the time period bucket.</li></ul></li><li id="ul0129-0552" num="1925">472. The process of embodiment 461, further, comprising:</li><li id="ul0129-0553" num="1926">the simulation selection interaction-interface mechanism is structured to comprise a pricing date selection interaction-interface mechanism and a simulation model selection interaction-interface mechanism.</li><li id="ul0129-0554" num="1927">473. The process of embodiment 461, further, comprising:</li><li id="ul0129-0555" num="1928">the range of unfiltered simulated market factor values for a market factor structured to include an average simulated market factor value in the set of simulated market scenarios for the market factor; and</li><li id="ul0129-0556" num="1929">the range of filtered simulated market factor values for the market factor structured to include an average value in the set of filtered simulated market scenarios for the market factor.</li><li id="ul0129-0557" num="1930">474. The process of embodiment 461, further, comprising:</li><li id="ul0129-0558" num="1931">each market factor interaction-interface mechanism in the set of market factor interaction-interface mechanisms is structured to include a slider interaction-interface mechanism to affect user modification to a range of allowable values of a market factor associated with the respective market factor interaction-interface mechanism.</li><li id="ul0129-0559" num="1932">475. The process of embodiment 461, further, comprising:</li><li id="ul0129-0560" num="1933">the instructions to update the set of customized market factors based on the user modification are structured to comprise instructions to add the modified market factor to the set of customized market factors.</li><li id="ul0129-0561" num="1934">476. The process of embodiment 461, further, comprising:</li><li id="ul0129-0562" num="1935">the instructions to update the set of customized market factors based on the user modification are structured to comprise instructions to remove the modified market factor from the set of customized market factors.</li><li id="ul0129-0563" num="1936">477. The process of embodiment 461, further, comprising:</li><li id="ul0129-0564" num="1937">the processor-executable instructions structured as: <ul id="ul0316" list-style="none"><li id="ul0316-0001" num="1938">generate, via at least one processor, a predefined scenario datastructure that includes a simulation identifier associated with the set of simulated market scenarios, identifiers of customized market factors from the set of customized market factors, and the ranges of allowable values for the set of customized market factors.</li></ul></li><li id="ul0129-0565" num="1939">478. The process of embodiment 461, further, comprising:</li><li id="ul0129-0566" num="1940">the processor-executable instructions structured as: <ul id="ul0317" list-style="none"><li id="ul0317-0001" num="1941">generate, via at least one processor, a predefined scenario datastructure that includes a simulation identifier associated with the set of simulated market scenarios, and identifiers of filtered simulated market scenarios from the set of filtered simulated market scenarios.</li></ul></li><li id="ul0129-0567" num="1942">479. The process of embodiment 461, further, comprising:</li><li id="ul0129-0568" num="1943">the processor-executable instructions structured as: <ul id="ul0318" list-style="none"><li id="ul0318-0001" num="1944">generate, via at least one processor, a set of factor group filter interaction-interface mechanisms, each factor group filter interaction-interface mechanism in the set of factor group filter interaction-interface mechanisms structured to be associated with a subset of market factor interaction-interface mechanisms from the set of market factor interaction-interface mechanisms.</li></ul></li><li id="ul0129-0569" num="1945">480. The process of embodiment 479, further, comprising:</li><li id="ul0129-0570" num="1946">the processor-executable instructions structured as: <ul id="ul0319" list-style="none"><li id="ul0319-0001" num="1947">obtain, via at least one processor, a user selection of a factor group filter interaction-interface mechanism in the set of factor group filter interaction-interface mechanisms; and</li><li id="ul0319-0002" num="1948">generate, via at least one processor, a filtered set of market factor interaction-interface mechanisms, each filtered market factor interaction-interface mechanism in the set of filtered market factor interaction-interface mechanisms structured to be associated with the selected factor group filter interaction-interface mechanism.</li></ul></li><li id="ul0129-0571" num="1949">501. A machine learning portfolio return computation engine apparatus, comprising:</li><li id="ul0129-0572" num="1950">a memory;</li><li id="ul0129-0573" num="1951">a component collection in the memory;</li><li id="ul0129-0574" num="1952">a processor disposed in communication with the memory and configured to issue a plurality of processor-executable instructions from the component collection, the processor-executable instructions structured as: <ul id="ul0320" list-style="none"><li id="ul0320-0001" num="1953">obtain, via at least one processor, a portfolio return computation request datastructure, the portfolio return computation request datastructure structured to specify a set of simulated market scenarios and a set of filters, the set of simulated market scenarios generated using a set of deep learning neural networks, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0320-0002" num="1954">determine, via at least one processor, a set of constituent portfolio securities of a portfolio, each constituent portfolio security in the set of constituent portfolio securities associated with a portfolio security weight of the respective constituent portfolio security in the portfolio;</li><li id="ul0320-0003" num="1955">filter, via at least one processor, the set of simulated market scenarios based on the set of filters to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each filter in the set of filters;</li><li id="ul0320-0004" num="1956">retrieve, via at least one processor, a set of expected returns for the set of constituent portfolio securities of the portfolio for the set of filtered simulated market scenarios;</li><li id="ul0320-0005" num="1957">calculate, via at least one processor, for each constituent portfolio security in the set of constituent portfolio securities, an expected constituent portfolio security return for the set of filtered simulated market scenarios as an average of expected returns in the set of expected returns of the respective constituent portfolio security; and</li><li id="ul0320-0006" num="1958">calculate, via at least one processor, an expected portfolio return for the set of filtered simulated market scenarios as a weighted average of the calculated expected constituent portfolio security returns for the set of filtered simulated market scenarios, an expected constituent portfolio security return weighted in accordance with the portfolio security weight of the associated portfolio security.</li></ul></li><li id="ul0129-0575" num="1959">502. The apparatus of embodiment 501, further, comprising:</li><li id="ul0129-0576" num="1960">the instructions to generate the set of simulated market scenarios using the set of deep learning neural networks are structured to comprise instructions to: <ul id="ul0321" list-style="none"><li id="ul0321-0001" num="1961">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0321-0002" num="1962">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0321-0003" num="1963">train, via at least one processor, for each time period bucket from the set of time period buckets, a deep learning neural network, from the set of deep learning neural networks, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0321-0004" num="1964">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained deep learning neural network associated with the respective time period bucket; and</li><li id="ul0321-0005" num="1965">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained deep learning neural network associated with the respective time period bucket.</li></ul></li><li id="ul0129-0577" num="1966">503. The apparatus of embodiment 502, further, comprising:</li><li id="ul0129-0578" num="1967">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0322" list-style="none"><li id="ul0322-0001" num="1968">determine, via at least one processor, a historical data set, a rolling window period length, and the set of market factors;</li><li id="ul0322-0002" num="1969">determine, via at least one processor, a set of rolling window periods using the historical data set and the rolling window period length; and</li><li id="ul0322-0003" num="1970">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0323" list-style="none"><li id="ul0323-0001" num="1971">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0579" num="1972">504. The apparatus of embodiment 503, further, comprising:</li><li id="ul0129-0580" num="1973">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0324" list-style="none"><li id="ul0324-0001" num="1974">determine, via at least one processor, the delta between values of the market factor at a beginning time point and an ending time point of the rolling window period.</li></ul></li><li id="ul0129-0581" num="1975">505. The apparatus of embodiment 504, further, comprising:</li><li id="ul0129-0582" num="1976">the processor-executable instructions structured as: <ul id="ul0325" list-style="none"><li id="ul0325-0001" num="1977">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0325-0002" num="1978">impute, via at least one processor, the unavailable historical data for the time point using a machine learning method.</li></ul></li><li id="ul0129-0583" num="1979">506. The apparatus of embodiment 503, further, comprising:</li><li id="ul0129-0584" num="1980">the rolling window period length is structured to be equal to the time period length.</li><li id="ul0129-0585" num="1981">507. The apparatus of embodiment 502, further, comprising:</li><li id="ul0129-0586" num="1982">the set of time period buckets is structured to have an equal fixed length for each time period bucket.</li><li id="ul0129-0587" num="1983">508. The apparatus of embodiment 502, further, comprising:</li><li id="ul0129-0588" num="1984">the set of time period buckets is structured to have a variable length for each time period bucket, the variable length for each time period bucket determined by judging the overall goodness of fit between the set of simulated market scenarios and the set of historical market scenarios.</li><li id="ul0129-0589" num="1985">509. The apparatus of embodiment 502, further, comprising:</li><li id="ul0129-0590" num="1986">the instructions to train a deep learning neural network for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0326" list-style="none"><li id="ul0326-0001" num="1987">select, via at least one processor, a historical market scenario from the associated subset of historical market scenarios; and</li><li id="ul0326-0002" num="1988">train, via at least one processor, the deep learning neural network for the time period bucket on the selected historical market scenario using a variational autoencoder.</li></ul></li><li id="ul0129-0591" num="1989">510. The apparatus of embodiment 509, further, comprising:</li><li id="ul0129-0592" num="1990">the deep learning neural network for the time period bucket is trained to generate a set of Gaussian mixture latent variables.</li><li id="ul0129-0593" num="1991">511. The apparatus of embodiment 510, further, comprising:</li><li id="ul0129-0594" num="1992">the instructions to generate simulated market scenarios for the time period bucket, using the trained deep learning neural network associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0327" list-style="none"><li id="ul0327-0001" num="1993">generate, via at least one processor, a set of random values for the set of Gaussian mixture latent variables; and</li><li id="ul0327-0002" num="1994">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, from the generated set of random values using a neural network decoder of the trained deep learning neural network associated with the time period bucket.</li></ul></li><li id="ul0129-0595" num="1995">512. The apparatus of embodiment 501, further, comprising:</li><li id="ul0129-0596" num="1996">a filter in the set of filters is configured as a set of customized market factors from the set of market factors and a range of allowable values for each customized market factor from the set of customized market factors.</li><li id="ul0129-0597" num="1997">513. The apparatus of embodiment 512, further, comprising:</li><li id="ul0129-0598" num="1998">the instructions to filter the set of simulated market scenarios based on the set of filters are structured to comprise instructions to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each customized market factors from the set of customized market factors.</li><li id="ul0129-0599" num="1999">514. The apparatus of embodiment 501, further, comprising:</li><li id="ul0129-0600" num="2000">a filter in the set of filters is configured as a business cycle identifier and a business cycle weight associated with the business cycle identifier.</li><li id="ul0129-0601" num="2001">515. The apparatus of embodiment 514, further, comprising:</li><li id="ul0129-0602" num="2002">the processor-executable instructions structured as: <ul id="ul0328" list-style="none"><li id="ul0328-0001" num="2003">calculate, via at least one processor, a weighted expected portfolio return for the portfolio as a weighted average of calculated expected portfolio returns for a set of business cycle identifiers, the set of business cycle identifiers including the business cycle identifier, the calculated expected portfolio return associated with the business cycle identifier weighted in accordance with the business cycle weight.</li></ul></li><li id="ul0129-0603" num="2004">516. A machine learning portfolio return computation engine processor-readable, non-transient medium, comprising processor-executable instructions structured as: <ul id="ul0329" list-style="none"><li id="ul0329-0001" num="2005">obtain, via at least one processor, a portfolio return computation request datastructure, the portfolio return computation request datastructure structured to specify a set of simulated market scenarios and a set of filters, the set of simulated market scenarios generated using a set of deep learning neural networks, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0329-0002" num="2006">determine, via at least one processor, a set of constituent portfolio securities of a portfolio, each constituent portfolio security in the set of constituent portfolio securities associated with a portfolio security weight of the respective constituent portfolio security in the portfolio;</li><li id="ul0329-0003" num="2007">filter, via at least one processor, the set of simulated market scenarios based on the set of filters to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each filter in the set of filters;</li><li id="ul0329-0004" num="2008">retrieve, via at least one processor, a set of expected returns for the set of constituent portfolio securities of the portfolio for the set of filtered simulated market scenarios;</li><li id="ul0329-0005" num="2009">calculate, via at least one processor, for each constituent portfolio security in the set of constituent portfolio securities, an expected constituent portfolio security return for the set of filtered simulated market scenarios as an average of expected returns in the set of expected returns of the respective constituent portfolio security; and</li><li id="ul0329-0006" num="2010">calculate, via at least one processor, an expected portfolio return for the set of filtered simulated market scenarios as a weighted average of the calculated expected constituent portfolio security returns for the set of filtered simulated market scenarios, an expected constituent portfolio security return weighted in accordance with the portfolio security weight of the associated portfolio security.</li></ul></li><li id="ul0129-0604" num="2011">517. The medium of embodiment 516, further, comprising:</li><li id="ul0129-0605" num="2012">the instructions to generate the set of simulated market scenarios using the set of deep learning neural networks are structured to comprise instructions to: <ul id="ul0330" list-style="none"><li id="ul0330-0001" num="2013">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0330-0002" num="2014">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0330-0003" num="2015">train, via at least one processor, for each time period bucket from the set of time period buckets, a deep learning neural network, from the set of deep learning neural networks, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0330-0004" num="2016">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained deep learning neural network associated with the respective time period bucket; and</li><li id="ul0330-0005" num="2017">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained deep learning neural network associated with the respective time period bucket.</li></ul></li><li id="ul0129-0606" num="2018">518. The medium of embodiment 517, further, comprising:</li><li id="ul0129-0607" num="2019">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0331" list-style="none"><li id="ul0331-0001" num="2020">determine, via at least one processor, a historical data set, a rolling window period length, and the set of market factors;</li><li id="ul0331-0002" num="2021">determine, via at least one processor, a set of rolling window periods using the historical data set and the rolling window period length; and</li><li id="ul0331-0003" num="2022">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0332" list-style="none"><li id="ul0332-0001" num="2023">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0608" num="2024">519. The medium of embodiment 518, further, comprising:</li><li id="ul0129-0609" num="2025">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0333" list-style="none"><li id="ul0333-0001" num="2026">determine, via at least one processor, the delta between values of the market factor at a beginning time point and an ending time point of the rolling window period.</li></ul></li><li id="ul0129-0610" num="2027">520. The medium of embodiment 519, further, comprising:</li><li id="ul0129-0611" num="2028">the processor-executable instructions structured as: <ul id="ul0334" list-style="none"><li id="ul0334-0001" num="2029">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0334-0002" num="2030">impute, via at least one processor, the unavailable historical data for the time point using a machine learning method.</li></ul></li><li id="ul0129-0612" num="2031">521. The medium of embodiment 518, further, comprising:</li><li id="ul0129-0613" num="2032">the rolling window period length is structured to be equal to the time period length.</li><li id="ul0129-0614" num="2033">522. The medium of embodiment 517, further, comprising:</li><li id="ul0129-0615" num="2034">the set of time period buckets is structured to have an equal fixed length for each time period bucket.</li><li id="ul0129-0616" num="2035">523. The medium of embodiment 517, further, comprising:</li><li id="ul0129-0617" num="2036">the set of time period buckets is structured to have a variable length for each time period bucket, the variable length for each time period bucket determined by judging the overall goodness of fit between the set of simulated market scenarios and the set of historical market scenarios.</li><li id="ul0129-0618" num="2037">524. The medium of embodiment 517, further, comprising:</li><li id="ul0129-0619" num="2038">the instructions to train a deep learning neural network for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0335" list-style="none"><li id="ul0335-0001" num="2039">select, via at least one processor, a historical market scenario from the associated subset of historical market scenarios; and</li><li id="ul0335-0002" num="2040">train, via at least one processor, the deep learning neural network for the time period bucket on the selected historical market scenario using a variational autoencoder.</li></ul></li><li id="ul0129-0620" num="2041">525. The medium of embodiment 524, further, comprising:</li><li id="ul0129-0621" num="2042">the deep learning neural network for the time period bucket is trained to generate a set of Gaussian mixture latent variables.</li><li id="ul0129-0622" num="2043">526. The medium of embodiment 525, further, comprising:</li><li id="ul0129-0623" num="2044">the instructions to generate simulated market scenarios for the time period bucket, using the trained deep learning neural network associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0336" list-style="none"><li id="ul0336-0001" num="2045">generate, via at least one processor, a set of random values for the set of Gaussian mixture latent variables; and</li><li id="ul0336-0002" num="2046">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, from the generated set of random values using a neural network decoder of the trained deep learning neural network associated with the time period bucket.</li></ul></li><li id="ul0129-0624" num="2047">527. The medium of embodiment 516, further, comprising:</li><li id="ul0129-0625" num="2048">a filter in the set of filters is configured as a set of customized market factors from the set of market factors and a range of allowable values for each customized market factor from the set of customized market factors.</li><li id="ul0129-0626" num="2049">528. The medium of embodiment 527, further, comprising:</li><li id="ul0129-0627" num="2050">the instructions to filter the set of simulated market scenarios based on the set of filters are structured to comprise instructions to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each customized market factors from the set of customized market factors.</li><li id="ul0129-0628" num="2051">529. The medium of embodiment 516, further, comprising:</li><li id="ul0129-0629" num="2052">a filter in the set of filters is configured as a business cycle identifier and a business cycle weight associated with the business cycle identifier.</li><li id="ul0129-0630" num="2053">530. The medium of embodiment 529, further, comprising:</li><li id="ul0129-0631" num="2054">the processor-executable instructions structured as: <ul id="ul0337" list-style="none"><li id="ul0337-0001" num="2055">calculate, via at least one processor, a weighted expected portfolio return for the portfolio as a weighted average of calculated expected portfolio returns for a set of business cycle identifiers, the set of business cycle identifiers including the business cycle identifier, the calculated expected portfolio return associated with the business cycle identifier weighted in accordance with the business cycle weight.</li></ul></li><li id="ul0129-0632" num="2056">531. A machine learning portfolio return computation engine processor-implemented system, comprising:</li><li id="ul0129-0633" num="2057">means to process processor-executable instructions;</li><li id="ul0129-0634" num="2058">means to issue processor-issuable instructions from a processor-executable component collection via the means to process processor-executable instructions, the processor-issuable instructions structured as: <ul id="ul0338" list-style="none"><li id="ul0338-0001" num="2059">obtain, via at least one processor, a portfolio return computation request datastructure, the portfolio return computation request datastructure structured to specify a set of simulated market scenarios and a set of filters, the set of simulated market scenarios generated using a set of deep learning neural networks, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0338-0002" num="2060">determine, via at least one processor, a set of constituent portfolio securities of a portfolio, each constituent portfolio security in the set of constituent portfolio securities associated with a portfolio security weight of the respective constituent portfolio security in the portfolio;</li><li id="ul0338-0003" num="2061">filter, via at least one processor, the set of simulated market scenarios based on the set of filters to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each filter in the set of filters;</li><li id="ul0338-0004" num="2062">retrieve, via at least one processor, a set of expected returns for the set of constituent portfolio securities of the portfolio for the set of filtered simulated market scenarios;</li><li id="ul0338-0005" num="2063">calculate, via at least one processor, for each constituent portfolio security in the set of constituent portfolio securities, an expected constituent portfolio security return for the set of filtered simulated market scenarios as an average of expected returns in the set of expected returns of the respective constituent portfolio security; and</li><li id="ul0338-0006" num="2064">calculate, via at least one processor, an expected portfolio return for the set of filtered simulated market scenarios as a weighted average of the calculated expected constituent portfolio security returns for the set of filtered simulated market scenarios, an expected constituent portfolio security return weighted in accordance with the portfolio security weight of the associated portfolio security.</li></ul></li><li id="ul0129-0635" num="2065">532. The system of embodiment 531, further, comprising:</li><li id="ul0129-0636" num="2066">the instructions to generate the set of simulated market scenarios using the set of deep learning neural networks are structured to comprise instructions to: <ul id="ul0339" list-style="none"><li id="ul0339-0001" num="2067">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0339-0002" num="2068">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0339-0003" num="2069">train, via at least one processor, for each time period bucket from the set of time period buckets, a deep learning neural network, from the set of deep learning neural networks, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0339-0004" num="2070">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained deep learning neural network associated with the respective time period bucket; and</li><li id="ul0339-0005" num="2071">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained deep learning neural network associated with the respective time period bucket.</li></ul></li><li id="ul0129-0637" num="2072">533. The system of embodiment 532, further, comprising:</li><li id="ul0129-0638" num="2073">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0340" list-style="none"><li id="ul0340-0001" num="2074">determine, via at least one processor, a historical data set, a rolling window period length, and the set of market factors;</li><li id="ul0340-0002" num="2075">determine, via at least one processor, a set of rolling window periods using the historical data set and the rolling window period length; and</li><li id="ul0340-0003" num="2076">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0341" list-style="none"><li id="ul0341-0001" num="2077">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0639" num="2078">534. The system of embodiment 533, further, comprising:</li><li id="ul0129-0640" num="2079">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0342" list-style="none"><li id="ul0342-0001" num="2080">determine, via at least one processor, the delta between values of the market factor at a beginning time point and an ending time point of the rolling window period.</li></ul></li><li id="ul0129-0641" num="2081">535. The system of embodiment 534, further, comprising:</li><li id="ul0129-0642" num="2082">the processor-executable instructions structured as: <ul id="ul0343" list-style="none"><li id="ul0343-0001" num="2083">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0343-0002" num="2084">impute, via at least one processor, the unavailable historical data for the time point using a machine learning method.</li></ul></li><li id="ul0129-0643" num="2085">536. The system of embodiment 533, further, comprising:</li><li id="ul0129-0644" num="2086">the rolling window period length is structured to be equal to the time period length.</li><li id="ul0129-0645" num="2087">537. The system of embodiment 532, further, comprising:</li><li id="ul0129-0646" num="2088">the set of time period buckets is structured to have an equal fixed length for each time period bucket.</li><li id="ul0129-0647" num="2089">538. The system of embodiment 532, further, comprising:</li><li id="ul0129-0648" num="2090">the set of time period buckets is structured to have a variable length for each time period bucket, the variable length for each time period bucket determined by judging the overall goodness of fit between the set of simulated market scenarios and the set of historical market scenarios.</li><li id="ul0129-0649" num="2091">539. The system of embodiment 532, further, comprising:</li><li id="ul0129-0650" num="2092">the instructions to train a deep learning neural network for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0344" list-style="none"><li id="ul0344-0001" num="2093">select, via at least one processor, a historical market scenario from the associated subset of historical market scenarios; and</li><li id="ul0344-0002" num="2094">train, via at least one processor, the deep learning neural network for the time period bucket on the selected historical market scenario using a variational autoencoder.</li></ul></li><li id="ul0129-0651" num="2095">540. The system of embodiment 539, further, comprising:</li><li id="ul0129-0652" num="2096">the deep learning neural network for the time period bucket is trained to generate a set of Gaussian mixture latent variables.</li><li id="ul0129-0653" num="2097">541. The system of embodiment 540, further, comprising:</li><li id="ul0129-0654" num="2098">the instructions to generate simulated market scenarios for the time period bucket, using the trained deep learning neural network associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0345" list-style="none"><li id="ul0345-0001" num="2099">generate, via at least one processor, a set of random values for the set of Gaussian mixture latent variables; and</li><li id="ul0345-0002" num="2100">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, from the generated set of random values using a neural network decoder of the trained deep learning neural network associated with the time period bucket.</li></ul></li><li id="ul0129-0655" num="2101">542. The system of embodiment 531, further, comprising:</li><li id="ul0129-0656" num="2102">a filter in the set of filters is configured as a set of customized market factors from the set of market factors and a range of allowable values for each customized market factor from the set of customized market factors.</li><li id="ul0129-0657" num="2103">543. The system of embodiment 542, further, comprising:</li><li id="ul0129-0658" num="2104">the instructions to filter the set of simulated market scenarios based on the set of filters are structured to comprise instructions to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each customized market factors from the set of customized market factors.</li><li id="ul0129-0659" num="2105">544. The system of embodiment 531, further, comprising:</li><li id="ul0129-0660" num="2106">a filter in the set of filters is configured as a business cycle identifier and a business cycle weight associated with the business cycle identifier.</li><li id="ul0129-0661" num="2107">545. The system of embodiment 544, further, comprising:</li><li id="ul0129-0662" num="2108">the processor-executable instructions structured as: <ul id="ul0346" list-style="none"><li id="ul0346-0001" num="2109">calculate, via at least one processor, a weighted expected portfolio return for the portfolio as a weighted average of calculated expected portfolio returns for a set of business cycle identifiers, the set of business cycle identifiers including the business cycle identifier, the calculated expected portfolio return associated with the business cycle identifier weighted in accordance with the business cycle weight.</li></ul></li><li id="ul0129-0663" num="2110">546. A machine learning portfolio return computation engine processor-implemented process, comprising executing processor-executable instructions to: <ul id="ul0347" list-style="none"><li id="ul0347-0001" num="2111">obtain, via at least one processor, a portfolio return computation request datastructure, the portfolio return computation request datastructure structured to specify a set of simulated market scenarios and a set of filters, the set of simulated market scenarios generated using a set of deep learning neural networks, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0347-0002" num="2112">determine, via at least one processor, a set of constituent portfolio securities of a portfolio, each constituent portfolio security in the set of constituent portfolio securities associated with a portfolio security weight of the respective constituent portfolio security in the portfolio;</li><li id="ul0347-0003" num="2113">filter, via at least one processor, the set of simulated market scenarios based on the set of filters to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each filter in the set of filters;</li><li id="ul0347-0004" num="2114">retrieve, via at least one processor, a set of expected returns for the set of constituent portfolio securities of the portfolio for the set of filtered simulated market scenarios;</li><li id="ul0347-0005" num="2115">calculate, via at least one processor, for each constituent portfolio security in the set of constituent portfolio securities, an expected constituent portfolio security return for the set of filtered simulated market scenarios as an average of expected returns in the set of expected returns of the respective constituent portfolio security; and</li><li id="ul0347-0006" num="2116">calculate, via at least one processor, an expected portfolio return for the set of filtered simulated market scenarios as a weighted average of the calculated expected constituent portfolio security returns for the set of filtered simulated market scenarios, an expected constituent portfolio security return weighted in accordance with the portfolio security weight of the associated portfolio security.</li></ul></li><li id="ul0129-0664" num="2117">547. The process of embodiment 546, further, comprising:</li><li id="ul0129-0665" num="2118">the instructions to generate the set of simulated market scenarios using the set of deep learning neural networks are structured to comprise instructions to: <ul id="ul0348" list-style="none"><li id="ul0348-0001" num="2119">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0348-0002" num="2120">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0348-0003" num="2121">train, via at least one processor, for each time period bucket from the set of time period buckets, a deep learning neural network, from the set of deep learning neural networks, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0348-0004" num="2122">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained deep learning neural network associated with the respective time period bucket; and</li><li id="ul0348-0005" num="2123">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained deep learning neural network associated with the respective time period bucket.</li></ul></li><li id="ul0129-0666" num="2124">548. The process of embodiment 547, further, comprising:</li><li id="ul0129-0667" num="2125">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0349" list-style="none"><li id="ul0349-0001" num="2126">determine, via at least one processor, a historical data set, a rolling window period length, and the set of market factors;</li><li id="ul0349-0002" num="2127">determine, via at least one processor, a set of rolling window periods using the historical data set and the rolling window period length; and</li><li id="ul0349-0003" num="2128">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0350" list-style="none"><li id="ul0350-0001" num="2129">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0668" num="2130">549. The process of embodiment 548, further, comprising:</li><li id="ul0129-0669" num="2131">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0351" list-style="none"><li id="ul0351-0001" num="2132">determine, via at least one processor, the delta between values of the market factor at a beginning time point and an ending time point of the rolling window period.</li></ul></li><li id="ul0129-0670" num="2133">550. The process of embodiment 549, further, comprising:</li><li id="ul0129-0671" num="2134">the processor-executable instructions structured as: <ul id="ul0352" list-style="none"><li id="ul0352-0001" num="2135">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0352-0002" num="2136">impute, via at least one processor, the unavailable historical data for the time point using a machine learning method.</li></ul></li><li id="ul0129-0672" num="2137">551. The process of embodiment 548, further, comprising:</li><li id="ul0129-0673" num="2138">the rolling window period length is structured to be equal to the time period length.</li><li id="ul0129-0674" num="2139">552. The process of embodiment 547, further, comprising:</li><li id="ul0129-0675" num="2140">the set of time period buckets is structured to have an equal fixed length for each time period bucket.</li><li id="ul0129-0676" num="2141">553. The process of embodiment 547, further, comprising:</li><li id="ul0129-0677" num="2142">the set of time period buckets is structured to have a variable length for each time period bucket, the variable length for each time period bucket determined by judging the overall goodness of fit between the set of simulated market scenarios and the set of historical market scenarios.</li><li id="ul0129-0678" num="2143">554. The process of embodiment 547, further, comprising:</li><li id="ul0129-0679" num="2144">the instructions to train a deep learning neural network for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0353" list-style="none"><li id="ul0353-0001" num="2145">select, via at least one processor, a historical market scenario from the associated subset of historical market scenarios; and</li><li id="ul0353-0002" num="2146">train, via at least one processor, the deep learning neural network for the time period bucket on the selected historical market scenario using a variational autoencoder.</li></ul></li><li id="ul0129-0680" num="2147">555. The process of embodiment 554, further, comprising:</li><li id="ul0129-0681" num="2148">the deep learning neural network for the time period bucket is trained to generate a set of Gaussian mixture latent variables.</li><li id="ul0129-0682" num="2149">556. The process of embodiment 555, further, comprising:</li><li id="ul0129-0683" num="2150">the instructions to generate simulated market scenarios for the time period bucket, using the trained deep learning neural network associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0354" list-style="none"><li id="ul0354-0001" num="2151">generate, via at least one processor, a set of random values for the set of Gaussian mixture latent variables; and</li><li id="ul0354-0002" num="2152">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, from the generated set of random values using a neural network decoder of the trained deep learning neural network associated with the time period bucket.</li></ul></li><li id="ul0129-0684" num="2153">557. The process of embodiment 546, further, comprising:</li><li id="ul0129-0685" num="2154">a filter in the set of filters is configured as a set of customized market factors from the set of market factors and a range of allowable values for each customized market factor from the set of customized market factors.</li><li id="ul0129-0686" num="2155">558. The process of embodiment 557, further, comprising:</li><li id="ul0129-0687" num="2156">the instructions to filter the set of simulated market scenarios based on the set of filters are structured to comprise instructions to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each customized market factors from the set of customized market factors.</li><li id="ul0129-0688" num="2157">559. The process of embodiment 546, further, comprising:</li><li id="ul0129-0689" num="2158">a filter in the set of filters is configured as a business cycle identifier and a business cycle weight associated with the business cycle identifier.</li><li id="ul0129-0690" num="2159">560. The process of embodiment 559, further, comprising:</li><li id="ul0129-0691" num="2160">the processor-executable instructions structured as: <ul id="ul0355" list-style="none"><li id="ul0355-0001" num="2161">calculate, via at least one processor, a weighted expected portfolio return for the portfolio as a weighted average of calculated expected portfolio returns for a set of business cycle identifiers, the set of business cycle identifiers including the business cycle identifier, the calculated expected portfolio return associated with the business cycle identifier weighted in accordance with the business cycle weight.</li></ul></li><li id="ul0129-0692" num="2162">601. A machine learning portfolio return computation engine apparatus, comprising:</li><li id="ul0129-0693" num="2163">a memory;</li><li id="ul0129-0694" num="2164">a component collection in the memory;</li><li id="ul0129-0695" num="2165">a processor disposed in communication with the memory and configured to issue a plurality of processor-executable instructions from the component collection, the processor-executable instructions structured as: <ul id="ul0356" list-style="none"><li id="ul0356-0001" num="2166">obtain, via at least one processor, a portfolio return computation request datastructure, the portfolio return computation request datastructure structured to specify a set of simulated market scenarios and a set of filters, the set of simulated market scenarios generated using a set of multi-variate mixture datastructures, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0356-0002" num="2167">determine, via at least one processor, a set of constituent portfolio securities of a portfolio, each constituent portfolio security in the set of constituent portfolio securities associated with a portfolio security weight of the respective constituent portfolio security in the portfolio;</li><li id="ul0356-0003" num="2168">filter, via at least one processor, the set of simulated market scenarios based on the set of filters to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each filter in the set of filters;</li><li id="ul0356-0004" num="2169">retrieve, via at least one processor, a set of expected returns for the set of constituent portfolio securities of the portfolio for the set of filtered simulated market scenarios;</li><li id="ul0356-0005" num="2170">calculate, via at least one processor, for each constituent portfolio security in the set of constituent portfolio securities, an expected constituent portfolio security return for the set of filtered simulated market scenarios as an average of expected returns in the set of expected returns of the respective constituent portfolio security; and</li><li id="ul0356-0006" num="2171">calculate, via at least one processor, an expected portfolio return for the set of filtered simulated market scenarios as a weighted average of the calculated expected constituent portfolio security returns for the set of filtered simulated market scenarios, an expected constituent portfolio security return weighted in accordance with the portfolio security weight of the associated portfolio security.</li></ul></li><li id="ul0129-0696" num="2172">602. The apparatus of embodiment 601, further, comprising:</li><li id="ul0129-0697" num="2173">the instructions to generate the set of simulated market scenarios using the set of multi-variate mixture datastructures are structured to comprise instructions to <ul id="ul0357" list-style="none"><li id="ul0357-0001" num="2174">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0357-0002" num="2175">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0357-0003" num="2176">train, via at least one processor, for each time period bucket from the set of time period buckets, a multi-variate mixture datastructure, from the set of multi-variate mixture datastructures, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0357-0004" num="2177">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained multi-variate mixture datastructure associated with the respective time period bucket; and</li><li id="ul0357-0005" num="2178">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained multi-variate mixture datastructure associated with the respective time period bucket.</li></ul></li><li id="ul0129-0698" num="2179">603. The apparatus of embodiment 602, further, comprising:</li><li id="ul0129-0699" num="2180">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0358" list-style="none"><li id="ul0358-0001" num="2181">determine, via at least one processor, a historical data set and the set of market factors;</li><li id="ul0358-0002" num="2182">determine, via at least one processor, a set of rolling window periods for the historical data set; and</li><li id="ul0358-0003" num="2183">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0359" list-style="none"><li id="ul0359-0001" num="2184">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0700" num="2185">604. The apparatus of embodiment 603, further, comprising:</li><li id="ul0129-0701" num="2186">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0360" list-style="none"><li id="ul0360-0001" num="2187">determine, via at least one processor, the delta between values of the market factor at two time point of the rolling window period.</li></ul></li><li id="ul0129-0702" num="2188">605. The apparatus of embodiment 604, further, comprising:</li><li id="ul0129-0703" num="2189">the processor-executable instructions structured as: <ul id="ul0361" list-style="none"><li id="ul0361-0001" num="2190">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0361-0002" num="2191">impute, via at least one processor, the unavailable historical data for the time point using a k-Nearest Neighbors method.</li></ul></li><li id="ul0129-0704" num="2192">606. The apparatus of embodiment 603, further, comprising:</li><li id="ul0129-0705" num="2193">the length of a rolling window period is structured to be equal to the time period length.</li><li id="ul0129-0706" num="2194">607. The apparatus of embodiment 602, further, comprising:</li><li id="ul0129-0707" num="2195">the set of time period buckets is structured to have a fixed length for each time period bucket.</li><li id="ul0129-0708" num="2196">608. The apparatus of embodiment 602, further, comprising:</li><li id="ul0129-0709" num="2197">the set of time period buckets is structured to have variable lengths, the variable length for each time period bucket reflective of changes in volatilities and correlations of the set of historical market scenarios.</li><li id="ul0129-0710" num="2198">609. The apparatus of embodiment 603, further, comprising:</li><li id="ul0129-0711" num="2199">the instructions to train a multi-variate mixture datastructure for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0362" list-style="none"><li id="ul0362-0001" num="2200">determine, via at least one processor, for each market factor from the set of market factors, a distribution to use for the respective market factor for the time period bucket;</li><li id="ul0362-0002" num="2201">fit, via at least one processor, for each market factor from the set of market factors, the distribution to use for the respective market factor for the time period bucket using the associated subset of historical market scenarios;</li><li id="ul0362-0003" num="2202">determine, via at least one processor, a copula for the set of market factors for the time period bucket; and</li><li id="ul0362-0004" num="2203">train, via at least one processor, the multi-variate mixture datastructure for the time period bucket using the fitted distributions and the copula for the set of market factors.</li></ul></li><li id="ul0129-0712" num="2204">610. The apparatus of embodiment 609, further, comprising:</li><li id="ul0129-0713" num="2205">the instructions to fit the distribution to use for a market factor for the time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to calculate the mean of the market factor's values in the associated subset of historical market scenarios.</li><li id="ul0129-0714" num="2206">611. The apparatus of embodiment 602, further, comprising:</li><li id="ul0129-0715" num="2207">the instructions to generate simulated market scenarios for a time period bucket, using the trained multi-variate mixture datastructure associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0363" list-style="none"><li id="ul0363-0001" num="2208">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, by sampling the trained multi-variate mixture datastructure associated with the time period bucket.</li></ul></li><li id="ul0129-0716" num="2209">612. The apparatus of embodiment 601, further, comprising:</li><li id="ul0129-0717" num="2210">a filter in the set of filters is configured as a set of customized market factors from the set of market factors and a range of allowable values for each customized market factor from the set of customized market factors.</li><li id="ul0129-0718" num="2211">613. The apparatus of embodiment 612, further, comprising:</li><li id="ul0129-0719" num="2212">the instructions to filter the set of simulated market scenarios based on the set of filters are structured to comprise instructions to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each customized market factors from the set of customized market factors.</li><li id="ul0129-0720" num="2213">614. The apparatus of embodiment 601, further, comprising:</li><li id="ul0129-0721" num="2214">a filter in the set of filters is configured as a business cycle identifier and a business cycle weight associated with the business cycle identifier.</li><li id="ul0129-0722" num="2215">615. The apparatus of embodiment 614, further, comprising:</li><li id="ul0129-0723" num="2216">the processor-executable instructions structured as: <ul id="ul0364" list-style="none"><li id="ul0364-0001" num="2217">calculate, via at least one processor, a weighted expected portfolio return for the portfolio as a weighted average of calculated expected portfolio returns for a set of business cycle identifiers, the set of business cycle identifiers including the business cycle identifier, the calculated expected portfolio return associated with the business cycle identifier weighted in accordance with the business cycle weight.</li></ul></li><li id="ul0129-0724" num="2218">616. A machine learning portfolio return computation engine processor-readable, non-transient medium, comprising processor-executable instructions structured as: <ul id="ul0365" list-style="none"><li id="ul0365-0001" num="2219">obtain, via at least one processor, a portfolio return computation request datastructure, the portfolio return computation request datastructure structured to specify a set of simulated market scenarios and a set of filters, the set of simulated market scenarios generated using a set of multi-variate mixture datastructures, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0365-0002" num="2220">determine, via at least one processor, a set of constituent portfolio securities of a portfolio, each constituent portfolio security in the set of constituent portfolio securities associated with a portfolio security weight of the respective constituent portfolio security in the portfolio;</li><li id="ul0365-0003" num="2221">filter, via at least one processor, the set of simulated market scenarios based on the set of filters to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each filter in the set of filters;</li><li id="ul0365-0004" num="2222">retrieve, via at least one processor, a set of expected returns for the set of constituent portfolio securities of the portfolio for the set of filtered simulated market scenarios;</li><li id="ul0365-0005" num="2223">calculate, via at least one processor, for each constituent portfolio security in the set of constituent portfolio securities, an expected constituent portfolio security return for the set of filtered simulated market scenarios as an average of expected returns in the set of expected returns of the respective constituent portfolio security; and</li><li id="ul0365-0006" num="2224">calculate, via at least one processor, an expected portfolio return for the set of filtered simulated market scenarios as a weighted average of the calculated expected constituent portfolio security returns for the set of filtered simulated market scenarios, an expected constituent portfolio security return weighted in accordance with the portfolio security weight of the associated portfolio security.</li></ul></li><li id="ul0129-0725" num="2225">617. The medium of embodiment 616, further, comprising:</li><li id="ul0129-0726" num="2226">the instructions to generate the set of simulated market scenarios using the set of multi-variate mixture datastructures are structured to comprise instructions to <ul id="ul0366" list-style="none"><li id="ul0366-0001" num="2227">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0366-0002" num="2228">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0366-0003" num="2229">train, via at least one processor, for each time period bucket from the set of time period buckets, a multi-variate mixture datastructure, from the set of multi-variate mixture datastructures, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0366-0004" num="2230">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained multi-variate mixture datastructure associated with the respective time period bucket; and</li><li id="ul0366-0005" num="2231">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained multi-variate mixture datastructure associated with the respective time period bucket.</li></ul></li><li id="ul0129-0727" num="2232">618. The medium of embodiment 617, further, comprising:</li><li id="ul0129-0728" num="2233">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0367" list-style="none"><li id="ul0367-0001" num="2234">determine, via at least one processor, a historical data set and the set of market factors;</li><li id="ul0367-0002" num="2235">determine, via at least one processor, a set of rolling window periods for the historical data set; and</li><li id="ul0367-0003" num="2236">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0368" list-style="none"><li id="ul0368-0001" num="2237">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0729" num="2238">619. The medium of embodiment 618, further, comprising:</li><li id="ul0129-0730" num="2239">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0369" list-style="none"><li id="ul0369-0001" num="2240">determine, via at least one processor, the delta between values of the market factor at two time point of the rolling window period.</li></ul></li><li id="ul0129-0731" num="2241">620. The medium of embodiment 619, further, comprising:</li><li id="ul0129-0732" num="2242">the processor-executable instructions structured as: <ul id="ul0370" list-style="none"><li id="ul0370-0001" num="2243">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0370-0002" num="2244">impute, via at least one processor, the unavailable historical data for the time point using a k-Nearest Neighbors method.</li></ul></li><li id="ul0129-0733" num="2245">621. The medium of embodiment 618, further, comprising:</li><li id="ul0129-0734" num="2246">the length of a rolling window period is structured to be equal to the time period length.</li><li id="ul0129-0735" num="2247">622. The medium of embodiment 617, further, comprising:</li><li id="ul0129-0736" num="2248">the set of time period buckets is structured to have a fixed length for each time period bucket.</li><li id="ul0129-0737" num="2249">623. The medium of embodiment 617, further, comprising:</li><li id="ul0129-0738" num="2250">the set of time period buckets is structured to have variable lengths, the variable length for each time period bucket reflective of changes in volatilities and correlations of the set of historical market scenarios.</li><li id="ul0129-0739" num="2251">624. The medium of embodiment 618, further, comprising:</li><li id="ul0129-0740" num="2252">the instructions to train a multi-variate mixture datastructure for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0371" list-style="none"><li id="ul0371-0001" num="2253">determine, via at least one processor, for each market factor from the set of market factors, a distribution to use for the respective market factor for the time period bucket;</li><li id="ul0371-0002" num="2254">fit, via at least one processor, for each market factor from the set of market factors, the distribution to use for the respective market factor for the time period bucket using the associated subset of historical market scenarios;</li><li id="ul0371-0003" num="2255">determine, via at least one processor, a copula for the set of market factors for the time period bucket; and</li><li id="ul0371-0004" num="2256">train, via at least one processor, the multi-variate mixture datastructure for the time period bucket using the fitted distributions and the copula for the set of market factors.</li></ul></li><li id="ul0129-0741" num="2257">625. The medium of embodiment 624, further, comprising:</li><li id="ul0129-0742" num="2258">the instructions to fit the distribution to use for a market factor for the time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to calculate the mean of the market factor's values in the associated subset of historical market scenarios.</li><li id="ul0129-0743" num="2259">626. The medium of embodiment 617, further, comprising:</li><li id="ul0129-0744" num="2260">the instructions to generate simulated market scenarios for a time period bucket, using the trained multi-variate mixture datastructure associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0372" list-style="none"><li id="ul0372-0001" num="2261">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, by sampling the trained multi-variate mixture datastructure associated with the time period bucket.</li></ul></li><li id="ul0129-0745" num="2262">627. The medium of embodiment 616, further, comprising:</li><li id="ul0129-0746" num="2263">a filter in the set of filters is configured as a set of customized market factors from the set of market factors and a range of allowable values for each customized market factor from the set of customized market factors.</li><li id="ul0129-0747" num="2264">628. The medium of embodiment 627, further, comprising:</li><li id="ul0129-0748" num="2265">the instructions to filter the set of simulated market scenarios based on the set of filters are structured to comprise instructions to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each customized market factors from the set of customized market factors.</li><li id="ul0129-0749" num="2266">629. The medium of embodiment 616, further, comprising:</li><li id="ul0129-0750" num="2267">a filter in the set of filters is configured as a business cycle identifier and a business cycle weight associated with the business cycle identifier.</li><li id="ul0129-0751" num="2268">630. The medium of embodiment 629, further, comprising:</li><li id="ul0129-0752" num="2269">the processor-executable instructions structured as: <ul id="ul0373" list-style="none"><li id="ul0373-0001" num="2270">calculate, via at least one processor, a weighted expected portfolio return for the portfolio as a weighted average of calculated expected portfolio returns for a set of business cycle identifiers, the set of business cycle identifiers including the business cycle identifier, the calculated expected portfolio return associated with the business cycle identifier weighted in accordance with the business cycle weight.</li></ul></li><li id="ul0129-0753" num="2271">631. A machine learning portfolio return computation engine processor-implemented system, comprising:</li><li id="ul0129-0754" num="2272">means to process processor-executable instructions;</li><li id="ul0129-0755" num="2273">means to issue processor-issuable instructions from a processor-executable component collection via the means to process processor-executable instructions, the processor-issuable instructions structured as: <ul id="ul0374" list-style="none"><li id="ul0374-0001" num="2274">obtain, via at least one processor, a portfolio return computation request datastructure, the portfolio return computation request datastructure structured to specify a set of simulated market scenarios and a set of filters, the set of simulated market scenarios generated using a set of multi-variate mixture datastructures, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0374-0002" num="2275">determine, via at least one processor, a set of constituent portfolio securities of a portfolio, each constituent portfolio security in the set of constituent portfolio securities associated with a portfolio security weight of the respective constituent portfolio security in the portfolio;</li><li id="ul0374-0003" num="2276">filter, via at least one processor, the set of simulated market scenarios based on the set of filters to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each filter in the set of filters;</li><li id="ul0374-0004" num="2277">retrieve, via at least one processor, a set of expected returns for the set of constituent portfolio securities of the portfolio for the set of filtered simulated market scenarios;</li><li id="ul0374-0005" num="2278">calculate, via at least one processor, for each constituent portfolio security in the set of constituent portfolio securities, an expected constituent portfolio security return for the set of filtered simulated market scenarios as an average of expected returns in the set of expected returns of the respective constituent portfolio security; and</li><li id="ul0374-0006" num="2279">calculate, via at least one processor, an expected portfolio return for the set of filtered simulated market scenarios as a weighted average of the calculated expected constituent portfolio security returns for the set of filtered simulated market scenarios, an expected constituent portfolio security return weighted in accordance with the portfolio security weight of the associated portfolio security.</li></ul></li><li id="ul0129-0756" num="2280">632. The system of embodiment 631, further, comprising:</li><li id="ul0129-0757" num="2281">the instructions to generate the set of simulated market scenarios using the set of multi-variate mixture datastructures are structured to comprise instructions to <ul id="ul0375" list-style="none"><li id="ul0375-0001" num="2282">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0375-0002" num="2283">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0375-0003" num="2284">train, via at least one processor, for each time period bucket from the set of time period buckets, a multi-variate mixture datastructure, from the set of multi-variate mixture datastructures, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0375-0004" num="2285">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained multi-variate mixture datastructure associated with the respective time period bucket; and</li><li id="ul0375-0005" num="2286">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained multi-variate mixture datastructure associated with the respective time period bucket.</li></ul></li><li id="ul0129-0758" num="2287">633. The system of embodiment 632, further, comprising:</li><li id="ul0129-0759" num="2288">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0376" list-style="none"><li id="ul0376-0001" num="2289">determine, via at least one processor, a historical data set and the set of market factors;</li><li id="ul0376-0002" num="2290">determine, via at least one processor, a set of rolling window periods for the historical data set; and</li><li id="ul0376-0003" num="2291">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0377" list-style="none"><li id="ul0377-0001" num="2292">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0760" num="2293">634. The system of embodiment 633, further, comprising:</li><li id="ul0129-0761" num="2294">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0378" list-style="none"><li id="ul0378-0001" num="2295">determine, via at least one processor, the delta between values of the market factor at two time point of the rolling window period.</li></ul></li><li id="ul0129-0762" num="2296">635. The system of embodiment 634, further, comprising:</li><li id="ul0129-0763" num="2297">the processor-executable instructions structured as: <ul id="ul0379" list-style="none"><li id="ul0379-0001" num="2298">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0379-0002" num="2299">impute, via at least one processor, the unavailable historical data for the time point using a k-Nearest Neighbors method.</li></ul></li><li id="ul0129-0764" num="2300">636. The system of embodiment 633, further, comprising:</li><li id="ul0129-0765" num="2301">the length of a rolling window period is structured to be equal to the time period length.</li><li id="ul0129-0766" num="2302">637. The system of embodiment 632, further, comprising:</li><li id="ul0129-0767" num="2303">the set of time period buckets is structured to have a fixed length for each time period bucket.</li><li id="ul0129-0768" num="2304">638. The system of embodiment 632, further, comprising:</li><li id="ul0129-0769" num="2305">the set of time period buckets is structured to have variable lengths, the variable length for each time period bucket reflective of changes in volatilities and correlations of the set of historical market scenarios.</li><li id="ul0129-0770" num="2306">639. The system of embodiment 633, further, comprising:</li><li id="ul0129-0771" num="2307">the instructions to train a multi-variate mixture datastructure for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0380" list-style="none"><li id="ul0380-0001" num="2308">determine, via at least one processor, for each market factor from the set of market factors, a distribution to use for the respective market factor for the time period bucket;</li><li id="ul0380-0002" num="2309">fit, via at least one processor, for each market factor from the set of market factors, the distribution to use for the respective market factor for the time period bucket using the associated subset of historical market scenarios;</li><li id="ul0380-0003" num="2310">determine, via at least one processor, a copula for the set of market factors for the time period bucket; and</li><li id="ul0380-0004" num="2311">train, via at least one processor, the multi-variate mixture datastructure for the time period bucket using the fitted distributions and the copula for the set of market factors.</li></ul></li><li id="ul0129-0772" num="2312">640. The system of embodiment 639, further, comprising:</li><li id="ul0129-0773" num="2313">the instructions to fit the distribution to use for a market factor for the time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to calculate the mean of the market factor's values in the associated subset of historical market scenarios.</li><li id="ul0129-0774" num="2314">641. The system of embodiment 632, further, comprising:</li><li id="ul0129-0775" num="2315">the instructions to generate simulated market scenarios for a time period bucket, using the trained multi-variate mixture datastructure associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0381" list-style="none"><li id="ul0381-0001" num="2316">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, by sampling the trained multi-variate mixture datastructure associated with the time period bucket.</li></ul></li><li id="ul0129-0776" num="2317">642. The system of embodiment 631, further, comprising:</li><li id="ul0129-0777" num="2318">a filter in the set of filters is configured as a set of customized market factors from the set of market factors and a range of allowable values for each customized market factor from the set of customized market factors.</li><li id="ul0129-0778" num="2319">643. The system of embodiment 642, further, comprising:</li><li id="ul0129-0779" num="2320">the instructions to filter the set of simulated market scenarios based on the set of filters are structured to comprise instructions to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each customized market factors from the set of customized market factors.</li><li id="ul0129-0780" num="2321">644. The system of embodiment 631, further, comprising:</li><li id="ul0129-0781" num="2322">a filter in the set of filters is configured as a business cycle identifier and a business cycle weight associated with the business cycle identifier.</li><li id="ul0129-0782" num="2323">645. The system of embodiment 644, further, comprising:</li><li id="ul0129-0783" num="2324">the processor-executable instructions structured as: <ul id="ul0382" list-style="none"><li id="ul0382-0001" num="2325">calculate, via at least one processor, a weighted expected portfolio return for the portfolio as a weighted average of calculated expected portfolio returns for a set of business cycle identifiers, the set of business cycle identifiers including the business cycle identifier, the calculated expected portfolio return associated with the business cycle identifier weighted in accordance with the business cycle weight.</li></ul></li><li id="ul0129-0784" num="2326">646. A machine learning portfolio return computation engine processor-implemented process, comprising executing processor-executable instructions to: <ul id="ul0383" list-style="none"><li id="ul0383-0001" num="2327">obtain, via at least one processor, a portfolio return computation request datastructure, the portfolio return computation request datastructure structured to specify a set of simulated market scenarios and a set of filters, the set of simulated market scenarios generated using a set of multi-variate mixture datastructures, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0383-0002" num="2328">determine, via at least one processor, a set of constituent portfolio securities of a portfolio, each constituent portfolio security in the set of constituent portfolio securities associated with a portfolio security weight of the respective constituent portfolio security in the portfolio;</li><li id="ul0383-0003" num="2329">filter, via at least one processor, the set of simulated market scenarios based on the set of filters to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each filter in the set of filters;</li><li id="ul0383-0004" num="2330">retrieve, via at least one processor, a set of expected returns for the set of constituent portfolio securities of the portfolio for the set of filtered simulated market scenarios;</li><li id="ul0383-0005" num="2331">calculate, via at least one processor, for each constituent portfolio security in the set of constituent portfolio securities, an expected constituent portfolio security return for the set of filtered simulated market scenarios as an average of expected returns in the set of expected returns of the respective constituent portfolio security; and</li><li id="ul0383-0006" num="2332">calculate, via at least one processor, an expected portfolio return for the set of filtered simulated market scenarios as a weighted average of the calculated expected constituent portfolio security returns for the set of filtered simulated market scenarios, an expected constituent portfolio security return weighted in accordance with the portfolio security weight of the associated portfolio security.</li></ul></li><li id="ul0129-0785" num="2333">647. The process of embodiment 646, further, comprising:</li><li id="ul0129-0786" num="2334">the instructions to generate the set of simulated market scenarios using the set of multi-variate mixture datastructures are structured to comprise instructions to <ul id="ul0384" list-style="none"><li id="ul0384-0001" num="2335">determine, via at least one processor, a set of historical market scenarios and a set of time period buckets;</li><li id="ul0384-0002" num="2336">determine, via at least one processor, for each time period bucket from the set of time period buckets, a subset of historical market scenarios, from the set of historical market scenarios, associated with the respective time period bucket;</li><li id="ul0384-0003" num="2337">train, via at least one processor, for each time period bucket from the set of time period buckets, a multi-variate mixture datastructure, from the set of multi-variate mixture datastructures, using the subset of historical market scenarios associated with the respective time period bucket;</li><li id="ul0384-0004" num="2338">determine, via at least one processor, for each time period bucket from the set of time period buckets, a number of simulated market scenarios to generate using the trained multi-variate mixture datastructure associated with the respective time period bucket; and</li><li id="ul0384-0005" num="2339">generate, via at least one processor, for each time period bucket from the set of time period buckets, the determined number of simulated market scenarios for the respective time period bucket, using the trained multi-variate mixture datastructure associated with the respective time period bucket.</li></ul></li><li id="ul0129-0787" num="2340">648. The process of embodiment 647, further, comprising:</li><li id="ul0129-0788" num="2341">the instructions to determine the set of historical market scenarios are structured to comprise instructions to: <ul id="ul0385" list-style="none"><li id="ul0385-0001" num="2342">determine, via at least one processor, a historical data set and the set of market factors;</li><li id="ul0385-0002" num="2343">determine, via at least one processor, a set of rolling window periods for the historical data set; and</li><li id="ul0385-0003" num="2344">calculate, via at least one processor, for each market factor from the set of market factors, for each rolling window period from the set of rolling window periods, a change to the respective market factor during the respective rolling window period, <ul id="ul0386" list-style="none"><li id="ul0386-0001" num="2345">each historical market scenario from the set of historical market scenarios structured to comprise calculated changes to the set of market factors during a rolling window period.</li></ul></li></ul></li><li id="ul0129-0789" num="2346">649. The process of embodiment 648, further, comprising:</li><li id="ul0129-0790" num="2347">the instructions to calculate a change to a market factor during a rolling window period are structured to comprise instructions to: <ul id="ul0387" list-style="none"><li id="ul0387-0001" num="2348">determine, via at least one processor, the delta between values of the market factor at two time point of the rolling window period.</li></ul></li><li id="ul0129-0791" num="2349">650. The process of embodiment 649, further, comprising:</li><li id="ul0129-0792" num="2350">the processor-executable instructions structured as: <ul id="ul0388" list-style="none"><li id="ul0388-0001" num="2351">determine, via at least one processor, that historical data for the market factor during the rolling window period is unavailable for a time point; and</li><li id="ul0388-0002" num="2352">impute, via at least one processor, the unavailable historical data for the time point using a k-Nearest Neighbors method.</li></ul></li><li id="ul0129-0793" num="2353">651. The process of embodiment 648, further, comprising:</li><li id="ul0129-0794" num="2354">the length of a rolling window period is structured to be equal to the time period length.</li><li id="ul0129-0795" num="2355">652. The process of embodiment 647, further, comprising:</li><li id="ul0129-0796" num="2356">the set of time period buckets is structured to have a fixed length for each time period bucket.</li><li id="ul0129-0797" num="2357">653. The process of embodiment 647, further, comprising:</li><li id="ul0129-0798" num="2358">the set of time period buckets is structured to have variable lengths, the variable length for each time period bucket reflective of changes in volatilities and correlations of the set of historical market scenarios.</li><li id="ul0129-0799" num="2359">654. The process of embodiment 648, further, comprising:</li><li id="ul0129-0800" num="2360">the instructions to train a multi-variate mixture datastructure for a time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to: <ul id="ul0389" list-style="none"><li id="ul0389-0001" num="2361">determine, via at least one processor, for each market factor from the set of market factors, a distribution to use for the respective market factor for the time period bucket;</li><li id="ul0389-0002" num="2362">fit, via at least one processor, for each market factor from the set of market factors, the distribution to use for the respective market factor for the time period bucket using the associated subset of historical market scenarios;</li><li id="ul0389-0003" num="2363">determine, via at least one processor, a copula for the set of market factors for the time period bucket; and</li><li id="ul0389-0004" num="2364">train, via at least one processor, the multi-variate mixture datastructure for the time period bucket using the fitted distributions and the copula for the set of market factors.</li></ul></li><li id="ul0129-0801" num="2365">655. The process of embodiment 654, further, comprising:</li><li id="ul0129-0802" num="2366">the instructions to fit the distribution to use for a market factor for the time period bucket using the associated subset of historical market scenarios are structured to comprise instructions to calculate the mean of the market factor's values in the associated subset of historical market scenarios.</li><li id="ul0129-0803" num="2367">656. The process of embodiment 647, further, comprising:</li><li id="ul0129-0804" num="2368">the instructions to generate simulated market scenarios for a time period bucket, using the trained multi-variate mixture datastructure associated with the time period bucket, are structured to comprise instructions to: <ul id="ul0390" list-style="none"><li id="ul0390-0001" num="2369">generate a simulated market scenario, from the simulated market scenarios for the time period bucket, by sampling the trained multi-variate mixture datastructure associated with the time period bucket.</li></ul></li><li id="ul0129-0805" num="2370">657. The process of embodiment 646, further, comprising:</li><li id="ul0129-0806" num="2371">a filter in the set of filters is configured as a set of customized market factors from the set of market factors and a range of allowable values for each customized market factor from the set of customized market factors.</li><li id="ul0129-0807" num="2372">658. The process of embodiment 657, further, comprising:</li><li id="ul0129-0808" num="2373">the instructions to filter the set of simulated market scenarios based on the set of filters are structured to comprise instructions to determine a set of filtered simulated market scenarios having simulated market factor values that fall within the range of allowable values for each customized market factors from the set of customized market factors.</li><li id="ul0129-0809" num="2374">659. The process of embodiment 646, further, comprising:</li><li id="ul0129-0810" num="2375">a filter in the set of filters is configured as a business cycle identifier and a business cycle weight associated with the business cycle identifier.</li><li id="ul0129-0811" num="2376">660. The process of embodiment 659, further, comprising:</li><li id="ul0129-0812" num="2377">the processor-executable instructions structured as: <ul id="ul0391" list-style="none"><li id="ul0391-0001" num="2378">calculate, via at least one processor, a weighted expected portfolio return for the portfolio as a weighted average of calculated expected portfolio returns for a set of business cycle identifiers, the set of business cycle identifiers including the business cycle identifier, the calculated expected portfolio return associated with the business cycle identifier weighted in accordance with the business cycle weight.</li></ul></li><li id="ul0129-0813" num="2379">701. A database calculation engine apparatus, comprising:</li><li id="ul0129-0814" num="2380">a memory;</li><li id="ul0129-0815" num="2381">a component collection in the memory;</li><li id="ul0129-0816" num="2382">a processor disposed in communication with the memory and configured to issue a plurality of processor-executable instructions from the component collection, the processor-executable instructions structured as: <ul id="ul0392" list-style="none"><li id="ul0392-0001" num="2383">obtain, via at least one processor, an asset return metrics calculation request datastructure, the asset return metrics calculation request datastructure structured to specify a set of assets and a set of simulated market scenarios, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0392-0002" num="2384">determine, via at least one processor, a number of sessions to utilize for calculating asset return metrics data;</li><li id="ul0392-0003" num="2385">determine, via at least one processor, an assets range for a session based on the determined number of sessions to utilize, the assets range comprising a set of asset database table records for the set of assets to be processed by the session;</li><li id="ul0392-0004" num="2386">create, via at least one processor, an assets batch database table, the assets batch database table structured to comprise a set of asset database table records of a specified batch size from the assets range for the session;</li><li id="ul0392-0005" num="2387">create, via at least one processor, a factor simulations batch database table, the factor simulations batch database table structured to comprise a set of simulated market factor return values for the set of asset database table records in the assets batch database table;</li><li id="ul0392-0006" num="2388">create, via at least one processor, a factor exposures batch database table, the factor exposures batch database table structured to comprise a set of factor exposure database table records matching the set of asset database table records in the assets batch database table; and</li><li id="ul0392-0007" num="2389">calculate, via at least one processor, via a parallel SQL query, expected returns for the set of asset database table records in the assets batch database table, using the factor simulations batch database table and the factor exposures batch database table.</li></ul></li><li id="ul0129-0817" num="2390">702. The apparatus of embodiment 701, further, comprising:</li><li id="ul0129-0818" num="2391">the set of simulated market factor values for a simulated market scenario is configured as generated using a set of deep learning neural networks.</li><li id="ul0129-0819" num="2392">703. The apparatus of embodiment 701, further, comprising:</li><li id="ul0129-0820" num="2393">the set of simulated market factor values for a simulated market scenario is configured as generated using a set of multi-variate mixture datastructures.</li><li id="ul0129-0821" num="2394">704. The apparatus of embodiment 701, further, comprising:</li><li id="ul0129-0822" num="2395">the processor-executable instructions structured as: <ul id="ul0393" list-style="none"><li id="ul0393-0001" num="2396">filter, via at least one processor, asset database table records associated with the set of assets, based on available factor exposure database table records, using a SQL statement.</li></ul></li><li id="ul0129-0823" num="2397">705. The apparatus of embodiment 704, further, comprising:</li><li id="ul0129-0824" num="2398">the processor-executable instructions structured as: <ul id="ul0394" list-style="none"><li id="ul0394-0001" num="2399">filter, via at least one processor, simulated market scenario database table records associated with the set of simulated market scenarios, based on a subset of market factors from the set of market factors to which the filtered asset database table records have exposure, using a SQL statement.</li></ul></li><li id="ul0129-0825" num="2400">706. The apparatus of embodiment 701, further, comprising:</li><li id="ul0129-0826" num="2401">the number of sessions to utilize for calculating asset return metrics data is determined based on the number of available server processors and a specified degree of parallelism per session.</li><li id="ul0129-0827" num="2402">707. The apparatus of embodiment 701, further, comprising:</li><li id="ul0129-0828" num="2403">the assets batch database table, the factor simulations batch database table, and the factor exposures batch database table are temporary database tables.</li><li id="ul0129-0829" num="2404">708. The apparatus of embodiment 704, further, comprising:</li><li id="ul0129-0830" num="2405">the processor-executable instructions structured as: <ul id="ul0395" list-style="none"><li id="ul0395-0001" num="2406">filter, via at least one processor, at least one of call schedule database table records and put schedule database table records based on the filtered asset database table records.</li></ul></li><li id="ul0129-0831" num="2407">709. The apparatus of embodiment 708, further, comprising:</li><li id="ul0129-0832" num="2408">the processor-executable instructions structured as: <ul id="ul0396" list-style="none"><li id="ul0396-0001" num="2409">adjust, via at least one processor, via a parallel SQL query, the calculated expected returns for the set of asset database table records in the assets batch database table, based on at least one of the filtered call schedule database table records and the filtered put schedule database table records.</li></ul></li><li id="ul0129-0833" num="2410">710. The apparatus of embodiment 701, further, comprising:</li><li id="ul0129-0834" num="2411">the processor-executable instructions structured as: <ul id="ul0397" list-style="none"><li id="ul0397-0001" num="2412">transpose, via at least one processor, the calculated expected returns for the set of asset database table records in the assets batch database table into a wide array format; and</li><li id="ul0397-0002" num="2413">write, via at least one processor, via a parallel SQL query, the transposed expected returns to an asset simulation wide table.</li></ul></li><li id="ul0129-0835" num="2414">711. The apparatus of embodiment 710, further, comprising:</li><li id="ul0129-0836" num="2415">the asset simulation wide table formatted to facilitate efficient calculation of portfolio return metrics; and</li><li id="ul0129-0837" num="2416">the asset simulation wide table structured to be written to in parallel by query server processes from a plurality of utilized sessions.</li><li id="ul0129-0838" num="2417">712. The apparatus of embodiment 701, further, comprising:</li><li id="ul0129-0839" num="2418">the processor-executable instructions structured as: <ul id="ul0398" list-style="none"><li id="ul0398-0001" num="2419">calculate, via at least one processor, via a parallel SQL query, an asset return metric based on the calculated expected returns for the set of asset database table records in the assets batch database table;</li><li id="ul0398-0002" num="2420">transpose, via at least one processor, the calculated asset return metric for the set of asset database table records in the assets batch database table into a wide array format; and</li><li id="ul0398-0003" num="2421">write, via at least one processor, via a parallel SQL query, the transposed asset return metric to an asset simulation wide table.</li></ul></li><li id="ul0129-0840" num="2422">713. The apparatus of embodiment 701, further, comprising:</li><li id="ul0129-0841" num="2423">the processor-executable instructions structured as: <ul id="ul0399" list-style="none"><li id="ul0399-0001" num="2424">write, via at least one processor, via a parallel SQL query, the calculated expected returns to an asset measure table.</li></ul></li><li id="ul0129-0842" num="2425">714. The apparatus of embodiment 701, further, comprising:</li><li id="ul0129-0843" num="2426">the processor-executable instructions structured as: <ul id="ul0400" list-style="none"><li id="ul0400-0001" num="2427">calculate, via at least one processor, via a parallel SQL query, an asset return metric based on the calculated expected returns for the set of asset database table records in the assets batch database table; and</li><li id="ul0400-0002" num="2428">write, via at least one processor, via a parallel SQL query, the calculated asset return metric to an asset measure table.</li></ul></li><li id="ul0129-0844" num="2429">715. The apparatus of embodiment 714, further, comprising:</li><li id="ul0129-0845" num="2430">the asset measure table formatted to facilitate efficient calculation of security return metrics; and</li><li id="ul0129-0846" num="2431">the asset measure table structured to be written to in parallel by query server processes from a plurality of utilized sessions.</li><li id="ul0129-0847" num="2432">716. A database calculation engine processor-readable, non-transient medium, comprising processor-executable instructions structured as: <ul id="ul0401" list-style="none"><li id="ul0401-0001" num="2433">obtain, via at least one processor, an asset return metrics calculation request datastructure, the asset return metrics calculation request datastructure structured to specify a set of assets and a set of simulated market scenarios, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0401-0002" num="2434">determine, via at least one processor, a number of sessions to utilize for calculating asset return metrics data;</li><li id="ul0401-0003" num="2435">determine, via at least one processor, an assets range for a session based on the determined number of sessions to utilize, the assets range comprising a set of asset database table records for the set of assets to be processed by the session;</li><li id="ul0401-0004" num="2436">create, via at least one processor, an assets batch database table, the assets batch database table structured to comprise a set of asset database table records of a specified batch size from the assets range for the session;</li><li id="ul0401-0005" num="2437">create, via at least one processor, a factor simulations batch database table, the factor simulations batch database table structured to comprise a set of simulated market factor return values for the set of asset database table records in the assets batch database table;</li><li id="ul0401-0006" num="2438">create, via at least one processor, a factor exposures batch database table, the factor exposures batch database table structured to comprise a set of factor exposure database table records matching the set of asset database table records in the assets batch database table; and</li><li id="ul0401-0007" num="2439">calculate, via at least one processor, via a parallel SQL query, expected returns for the set of asset database table records in the assets batch database table, using the factor simulations batch database table and the factor exposures batch database table.</li></ul></li><li id="ul0129-0848" num="2440">717. The medium of embodiment 716, further, comprising:</li><li id="ul0129-0849" num="2441">the set of simulated market factor values for a simulated market scenario is configured as generated using a set of deep learning neural networks.</li><li id="ul0129-0850" num="2442">718. The medium of embodiment 716, further, comprising:</li><li id="ul0129-0851" num="2443">the set of simulated market factor values for a simulated market scenario is configured as generated using a set of multi-variate mixture datastructures.</li><li id="ul0129-0852" num="2444">719. The medium of embodiment 716, further, comprising:</li><li id="ul0129-0853" num="2445">the processor-executable instructions structured as: <ul id="ul0402" list-style="none"><li id="ul0402-0001" num="2446">filter, via at least one processor, asset database table records associated with the set of assets, based on available factor exposure database table records, using a SQL statement.</li></ul></li><li id="ul0129-0854" num="2447">720. The medium of embodiment 719, further, comprising:</li><li id="ul0129-0855" num="2448">the processor-executable instructions structured as: <ul id="ul0403" list-style="none"><li id="ul0403-0001" num="2449">filter, via at least one processor, simulated market scenario database table records associated with the set of simulated market scenarios, based on a subset of market factors from the set of market factors to which the filtered asset database table records have exposure, using a SQL statement.</li></ul></li><li id="ul0129-0856" num="2450">721. The medium of embodiment 716, further, comprising:</li><li id="ul0129-0857" num="2451">the number of sessions to utilize for calculating asset return metrics data is determined based on the number of available server processors and a specified degree of parallelism per session.</li><li id="ul0129-0858" num="2452">722. The medium of embodiment 716, further, comprising:</li><li id="ul0129-0859" num="2453">the assets batch database table, the factor simulations batch database table, and the factor exposures batch database table are temporary database tables.</li><li id="ul0129-0860" num="2454">723. The medium of embodiment 719, further, comprising:</li><li id="ul0129-0861" num="2455">the processor-executable instructions structured as: <ul id="ul0404" list-style="none"><li id="ul0404-0001" num="2456">filter, via at least one processor, at least one of call schedule database table records and put schedule database table records based on the filtered asset database table records.</li></ul></li><li id="ul0129-0862" num="2457">724. The medium of embodiment 723, further, comprising:</li><li id="ul0129-0863" num="2458">the processor-executable instructions structured as: <ul id="ul0405" list-style="none"><li id="ul0405-0001" num="2459">adjust, via at least one processor, via a parallel SQL query, the calculated expected returns for the set of asset database table records in the assets batch database table, based on at least one of the filtered call schedule database table records and the filtered put schedule database table records.</li></ul></li><li id="ul0129-0864" num="2460">725. The medium of embodiment 716, further, comprising:</li><li id="ul0129-0865" num="2461">the processor-executable instructions structured as: <ul id="ul0406" list-style="none"><li id="ul0406-0001" num="2462">transpose, via at least one processor, the calculated expected returns for the set of asset database table records in the assets batch database table into a wide array format; and</li><li id="ul0406-0002" num="2463">write, via at least one processor, via a parallel SQL query, the transposed expected returns to an asset simulation wide table.</li></ul></li><li id="ul0129-0866" num="2464">726. The medium of embodiment 725, further, comprising:</li><li id="ul0129-0867" num="2465">the asset simulation wide table formatted to facilitate efficient calculation of portfolio return metrics; and</li><li id="ul0129-0868" num="2466">the asset simulation wide table structured to be written to in parallel by query server processes from a plurality of utilized sessions.</li><li id="ul0129-0869" num="2467">727. The medium of embodiment 716, further, comprising:</li><li id="ul0129-0870" num="2468">the processor-executable instructions structured as: <ul id="ul0407" list-style="none"><li id="ul0407-0001" num="2469">calculate, via at least one processor, via a parallel SQL query, an asset return metric based on the calculated expected returns for the set of asset database table records in the assets batch database table;</li><li id="ul0407-0002" num="2470">transpose, via at least one processor, the calculated asset return metric for the set of asset database table records in the assets batch database table into a wide array format; and</li><li id="ul0407-0003" num="2471">write, via at least one processor, via a parallel SQL query, the transposed asset return metric to an asset simulation wide table.</li></ul></li><li id="ul0129-0871" num="2472">728. The medium of embodiment 716, further, comprising:</li><li id="ul0129-0872" num="2473">the processor-executable instructions structured as: <ul id="ul0408" list-style="none"><li id="ul0408-0001" num="2474">write, via at least one processor, via a parallel SQL query, the calculated expected returns to an asset measure table.</li></ul></li><li id="ul0129-0873" num="2475">729. The medium of embodiment 716, further, comprising:</li><li id="ul0129-0874" num="2476">the processor-executable instructions structured as: <ul id="ul0409" list-style="none"><li id="ul0409-0001" num="2477">calculate, via at least one processor, via a parallel SQL query, an asset return metric based on the calculated expected returns for the set of asset database table records in the assets batch database table; and</li><li id="ul0409-0002" num="2478">write, via at least one processor, via a parallel SQL query, the calculated asset return metric to an asset measure table.</li></ul></li><li id="ul0129-0875" num="2479">730. The medium of embodiment 729, further, comprising:</li><li id="ul0129-0876" num="2480">the asset measure table formatted to facilitate efficient calculation of security return metrics; and</li><li id="ul0129-0877" num="2481">the asset measure table structured to be written to in parallel by query server processes from a plurality of utilized sessions.</li><li id="ul0129-0878" num="2482">731. A database calculation engine processor-implemented system, comprising:</li><li id="ul0129-0879" num="2483">means to process processor-executable instructions;</li><li id="ul0129-0880" num="2484">means to issue processor-issuable instructions from a processor-executable component collection via the means to process processor-executable instructions, the processor-issuable instructions structured as: <ul id="ul0410" list-style="none"><li id="ul0410-0001" num="2485">obtain, via at least one processor, an asset return metrics calculation request datastructure, the asset return metrics calculation request datastructure structured to specify a set of assets and a set of simulated market scenarios, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0410-0002" num="2486">determine, via at least one processor, a number of sessions to utilize for calculating asset return metrics data;</li><li id="ul0410-0003" num="2487">determine, via at least one processor, an assets range for a session based on the determined number of sessions to utilize, the assets range comprising a set of asset database table records for the set of assets to be processed by the session;</li><li id="ul0410-0004" num="2488">create, via at least one processor, an assets batch database table, the assets batch database table structured to comprise a set of asset database table records of a specified batch size from the assets range for the session;</li><li id="ul0410-0005" num="2489">create, via at least one processor, a factor simulations batch database table, the factor simulations batch database table structured to comprise a set of simulated market factor return values for the set of asset database table records in the assets batch database table;</li><li id="ul0410-0006" num="2490">create, via at least one processor, a factor exposures batch database table, the factor exposures batch database table structured to comprise a set of factor exposure database table records matching the set of asset database table records in the assets batch database table; and</li><li id="ul0410-0007" num="2491">calculate, via at least one processor, via a parallel SQL query, expected returns for the set of asset database table records in the assets batch database table, using the factor simulations batch database table and the factor exposures batch database table.</li></ul></li><li id="ul0129-0881" num="2492">732. The system of embodiment 731, further, comprising:</li><li id="ul0129-0882" num="2493">the set of simulated market factor values for a simulated market scenario is configured as generated using a set of deep learning neural networks.</li><li id="ul0129-0883" num="2494">733. The system of embodiment 731, further, comprising:</li><li id="ul0129-0884" num="2495">the set of simulated market factor values for a simulated market scenario is configured as generated using a set of multi-variate mixture datastructures.</li><li id="ul0129-0885" num="2496">734. The system of embodiment 731, further, comprising:</li><li id="ul0129-0886" num="2497">the processor-executable instructions structured as: <ul id="ul0411" list-style="none"><li id="ul0411-0001" num="2498">filter, via at least one processor, asset database table records associated with the set of assets, based on available factor exposure database table records, using a SQL statement.</li></ul></li><li id="ul0129-0887" num="2499">735. The system of embodiment 734, further, comprising:</li><li id="ul0129-0888" num="2500">the processor-executable instructions structured as: <ul id="ul0412" list-style="none"><li id="ul0412-0001" num="2501">filter, via at least one processor, simulated market scenario database table records associated with the set of simulated market scenarios, based on a subset of market factors from the set of market factors to which the filtered asset database table records have exposure, using a SQL statement.</li></ul></li><li id="ul0129-0889" num="2502">736. The system of embodiment 731, further, comprising:</li><li id="ul0129-0890" num="2503">the number of sessions to utilize for calculating asset return metrics data is determined based on the number of available server processors and a specified degree of parallelism per session.</li><li id="ul0129-0891" num="2504">737. The system of embodiment 731, further, comprising:</li><li id="ul0129-0892" num="2505">the assets batch database table, the factor simulations batch database table, and the factor exposures batch database table are temporary database tables.</li><li id="ul0129-0893" num="2506">738. The system of embodiment 734, further, comprising:</li><li id="ul0129-0894" num="2507">the processor-executable instructions structured as: <ul id="ul0413" list-style="none"><li id="ul0413-0001" num="2508">filter, via at least one processor, at least one of call schedule database table records and put schedule database table records based on the filtered asset database table records.</li></ul></li><li id="ul0129-0895" num="2509">739. The system of embodiment 738, further, comprising:</li><li id="ul0129-0896" num="2510">the processor-executable instructions structured as: <ul id="ul0414" list-style="none"><li id="ul0414-0001" num="2511">adjust, via at least one processor, via a parallel SQL query, the calculated expected returns for the set of asset database table records in the assets batch database table, based on at least one of the filtered call schedule database table records and the filtered put schedule database table records.</li></ul></li><li id="ul0129-0897" num="2512">740. The system of embodiment 731, further, comprising:</li><li id="ul0129-0898" num="2513">the processor-executable instructions structured as: <ul id="ul0415" list-style="none"><li id="ul0415-0001" num="2514">transpose, via at least one processor, the calculated expected returns for the set of asset database table records in the assets batch database table into a wide array format; and</li><li id="ul0415-0002" num="2515">write, via at least one processor, via a parallel SQL query, the transposed expected returns to an asset simulation wide table.</li></ul></li><li id="ul0129-0899" num="2516">741. The system of embodiment 740, further, comprising:</li><li id="ul0129-0900" num="2517">the asset simulation wide table formatted to facilitate efficient calculation of portfolio return metrics; and</li><li id="ul0129-0901" num="2518">the asset simulation wide table structured to be written to in parallel by query server processes from a plurality of utilized sessions.</li><li id="ul0129-0902" num="2519">742. The system of embodiment 731, further, comprising:</li><li id="ul0129-0903" num="2520">the processor-executable instructions structured as: <ul id="ul0416" list-style="none"><li id="ul0416-0001" num="2521">calculate, via at least one processor, via a parallel SQL query, an asset return metric based on the calculated expected returns for the set of asset database table records in the assets batch database table;</li><li id="ul0416-0002" num="2522">transpose, via at least one processor, the calculated asset return metric for the set of asset database table records in the assets batch database table into a wide array format; and</li><li id="ul0416-0003" num="2523">write, via at least one processor, via a parallel SQL query, the transposed asset return metric to an asset simulation wide table.</li></ul></li><li id="ul0129-0904" num="2524">743. The system of embodiment 731, further, comprising:</li><li id="ul0129-0905" num="2525">the processor-executable instructions structured as: <ul id="ul0417" list-style="none"><li id="ul0417-0001" num="2526">write, via at least one processor, via a parallel SQL query, the calculated expected returns to an asset measure table.</li></ul></li><li id="ul0129-0906" num="2527">744. The system of embodiment 731, further, comprising:</li><li id="ul0129-0907" num="2528">the processor-executable instructions structured as: <ul id="ul0418" list-style="none"><li id="ul0418-0001" num="2529">calculate, via at least one processor, via a parallel SQL query, an asset return metric based on the calculated expected returns for the set of asset database table records in the assets batch database table; and</li><li id="ul0418-0002" num="2530">write, via at least one processor, via a parallel SQL query, the calculated asset return metric to an asset measure table.</li></ul></li><li id="ul0129-0908" num="2531">745. The system of embodiment 744, further, comprising:</li><li id="ul0129-0909" num="2532">the asset measure table formatted to facilitate efficient calculation of security return metrics; and</li><li id="ul0129-0910" num="2533">the asset measure table structured to be written to in parallel by query server processes from a plurality of utilized sessions.</li><li id="ul0129-0911" num="2534">746. A database calculation engine processor-implemented process, comprising executing processor-executable instructions to: <ul id="ul0419" list-style="none"><li id="ul0419-0001" num="2535">obtain, via at least one processor, an asset return metrics calculation request datastructure, the asset return metrics calculation request datastructure structured to specify a set of assets and a set of simulated market scenarios, each simulated market scenario in the set of simulated market scenarios structured to comprise a set of simulated market factor values corresponding to a set of market factors;</li><li id="ul0419-0002" num="2536">determine, via at least one processor, a number of sessions to utilize for calculating asset return metrics data;</li><li id="ul0419-0003" num="2537">determine, via at least one processor, an assets range for a session based on the determined number of sessions to utilize, the assets range comprising a set of asset database table records for the set of assets to be processed by the session;</li><li id="ul0419-0004" num="2538">create, via at least one processor, an assets batch database table, the assets batch database table structured to comprise a set of asset database table records of a specified batch size from the assets range for the session;</li><li id="ul0419-0005" num="2539">create, via at least one processor, a factor simulations batch database table, the factor simulations batch database table structured to comprise a set of simulated market factor return values for the set of asset database table records in the assets batch database table;</li><li id="ul0419-0006" num="2540">create, via at least one processor, a factor exposures batch database table, the factor exposures batch database table structured to comprise a set of factor exposure database table records matching the set of asset database table records in the assets batch database table; and</li><li id="ul0419-0007" num="2541">calculate, via at least one processor, via a parallel SQL query, expected returns for the set of asset database table records in the assets batch database table, using the factor simulations batch database table and the factor exposures batch database table.</li></ul></li><li id="ul0129-0912" num="2542">747. The process of embodiment 746, further, comprising:</li><li id="ul0129-0913" num="2543">the set of simulated market factor values for a simulated market scenario is configured as generated using a set of deep learning neural networks.</li><li id="ul0129-0914" num="2544">748. The process of embodiment 746, further, comprising:</li><li id="ul0129-0915" num="2545">the set of simulated market factor values for a simulated market scenario is configured as generated using a set of multi-variate mixture datastructures.</li><li id="ul0129-0916" num="2546">749. The process of embodiment 746, further, comprising:</li><li id="ul0129-0917" num="2547">the processor-executable instructions structured as: <ul id="ul0420" list-style="none"><li id="ul0420-0001" num="2548">filter, via at least one processor, asset database table records associated with the set of assets, based on available factor exposure database table records, using a SQL statement.</li></ul></li><li id="ul0129-0918" num="2549">750. The process of embodiment 749, further, comprising:</li><li id="ul0129-0919" num="2550">the processor-executable instructions structured as: <ul id="ul0421" list-style="none"><li id="ul0421-0001" num="2551">filter, via at least one processor, simulated market scenario database table records associated with the set of simulated market scenarios, based on a subset of market factors from the set of market factors to which the filtered asset database table records have exposure, using a SQL statement.</li></ul></li><li id="ul0129-0920" num="2552">751. The process of embodiment 746, further, comprising:</li><li id="ul0129-0921" num="2553">the number of sessions to utilize for calculating asset return metrics data is determined based on the number of available server processors and a specified degree of parallelism per session.</li><li id="ul0129-0922" num="2554">752. The process of embodiment 746, further, comprising:</li><li id="ul0129-0923" num="2555">the assets batch database table, the factor simulations batch database table, and the factor exposures batch database table are temporary database tables.</li><li id="ul0129-0924" num="2556">753. The process of embodiment 749, further, comprising:</li><li id="ul0129-0925" num="2557">the processor-executable instructions structured as: <ul id="ul0422" list-style="none"><li id="ul0422-0001" num="2558">filter, via at least one processor, at least one of call schedule database table records and put schedule database table records based on the filtered asset database table records.</li></ul></li><li id="ul0129-0926" num="2559">754. The process of embodiment 753, further, comprising:</li><li id="ul0129-0927" num="2560">the processor-executable instructions structured as: <ul id="ul0423" list-style="none"><li id="ul0423-0001" num="2561">adjust, via at least one processor, via a parallel SQL query, the calculated expected returns for the set of asset database table records in the assets batch database table, based on at least one of the filtered call schedule database table records and the filtered put schedule database table records.</li></ul></li><li id="ul0129-0928" num="2562">755. The process of embodiment 746, further, comprising:</li><li id="ul0129-0929" num="2563">the processor-executable instructions structured as: <ul id="ul0424" list-style="none"><li id="ul0424-0001" num="2564">transpose, via at least one processor, the calculated expected returns for the set of asset database table records in the assets batch database table into a wide array format; and</li><li id="ul0424-0002" num="2565">write, via at least one processor, via a parallel SQL query, the transposed expected returns to an asset simulation wide table.</li></ul></li><li id="ul0129-0930" num="2566">756. The process of embodiment 755, further, comprising:</li><li id="ul0129-0931" num="2567">the asset simulation wide table formatted to facilitate efficient calculation of portfolio return metrics; and</li><li id="ul0129-0932" num="2568">the asset simulation wide table structured to be written to in parallel by query server processes from a plurality of utilized sessions.</li><li id="ul0129-0933" num="2569">757. The process of embodiment 746, further, comprising:</li><li id="ul0129-0934" num="2570">the processor-executable instructions structured as: <ul id="ul0425" list-style="none"><li id="ul0425-0001" num="2571">calculate, via at least one processor, via a parallel SQL query, an asset return metric based on the calculated expected returns for the set of asset database table records in the assets batch database table;</li><li id="ul0425-0002" num="2572">transpose, via at least one processor, the calculated asset return metric for the set of asset database table records in the assets batch database table into a wide array format; and</li><li id="ul0425-0003" num="2573">write, via at least one processor, via a parallel SQL query, the transposed asset return metric to an asset simulation wide table.</li></ul></li><li id="ul0129-0935" num="2574">758. The process of embodiment 746, further, comprising:</li><li id="ul0129-0936" num="2575">the processor-executable instructions structured as: <ul id="ul0426" list-style="none"><li id="ul0426-0001" num="2576">write, via at least one processor, via a parallel SQL query, the calculated expected returns to an asset measure table.</li></ul></li><li id="ul0129-0937" num="2577">759. The process of embodiment 746, further, comprising:</li><li id="ul0129-0938" num="2578">the processor-executable instructions structured as: <ul id="ul0427" list-style="none"><li id="ul0427-0001" num="2579">calculate, via at least one processor, via a parallel SQL query, an asset return metric based on the calculated expected returns for the set of asset database table records in the assets batch database table; and</li><li id="ul0427-0002" num="2580">write, via at least one processor, via a parallel SQL query, the calculated asset return metric to an asset measure table.</li></ul></li><li id="ul0129-0939" num="2581">760. The process of embodiment 759, further, comprising:</li><li id="ul0129-0940" num="2582">the asset measure table formatted to facilitate efficient calculation of security return metrics; and</li><li id="ul0129-0941" num="2583">the asset measure table structured to be written to in parallel by query server processes from a plurality of utilized sessions.</li></ul>

MLPO Controller

2584<figref idref="DRAWINGS">FIG. 99</figref> shows a block diagram illustrating embodiments of a MLPO controller. In this embodiment, the MLPO controller <b>9901</b> may serve to aggregate, process, store, search, serve, identify, instruct, generate, match, and/or facilitate interactions with a computer through machine learning and database systems technologies, and/or other related data.

2585Users, which may be people and/or other systems, may engage information technology systems (e.g., computers) to facilitate information processing. In turn, computers employ processors to process information; such processors <b>9903</b> may be referred to as central processing units (CPU). One form of processor is referred to as a microprocessor. CPUs use communicative circuits to pass binary encoded signals acting as instructions to allow various operations. These instructions may be operational and/or data instructions containing and/or referencing other instructions and data in various processor accessible and operable areas of memory <b>9929</b> (e.g., registers, cache memory, random access memory, etc.). Such communicative instructions may be stored and/or transmitted in batches (e.g., batches of instructions) as programs and/or data components to facilitate desired operations. These stored instruction codes, e.g., programs, may engage the CPU circuit components and other motherboard and/or system components to perform desired operations. One type of program is a computer operating system, which, may be executed by CPU on a computer; the operating system enables and facilitates users to access and operate computer information technology and resources. Some resources that may be employed in information technology systems include: input and output mechanisms through which data may pass into and out of a computer; memory storage into which data may be saved; and processors by which information may be processed. These information technology systems may be used to collect data for later retrieval, analysis, and manipulation, which may be facilitated through a database program. These information technology systems provide interfaces that allow users to access and operate various system components.

2586In one embodiment, the MLPO controller <b>9901</b> may be connected to and/or communicate with entities such as, but not limited to: one or more users from peripheral devices <b>9912</b> (e.g., user input devices <b>9911</b>); an optional cryptographic processor device <b>9928</b>; and/or a communications network <b>9913</b>.

2587Networks comprise the interconnection and interoperation of clients, servers, and intermediary nodes in a graph topology. It should be noted that the term “server” as used throughout this application refers generally to a computer, other device, program, or combination thereof that processes and responds to the requests of remote users across a communications network. Servers serve their information to requesting “clients.” The term “client” as used herein refers generally to a computer, program, other device, user and/or combination thereof that is capable of processing and making requests and obtaining and processing any responses from servers across a communications network. A computer, other device, program, or combination thereof that facilitates, processes information and requests, and/or furthers the passage of information from a source user to a destination user is referred to as a “node.” Networks are generally thought to facilitate the transfer of information from source points to destinations. A node specifically tasked with furthering the passage of information from a source to a destination is called a “router.” There are many forms of networks such as Local Area Networks (LANs), Pico networks, Wide Area Networks (WANs), Wireless Networks (WLANs), etc. For example, the Internet is, generally, an interconnection of a multitude of networks whereby remote clients and servers may access and interoperate with one another.

2588The MLPO controller <b>9901</b> may be based on computer systems that may comprise, but are not limited to, components such as: a computer systemization <b>9902</b> connected to memory <b>9929</b>.

Computer Systemization

2589A computer systemization <b>9902</b> may comprise a clock <b>9930</b>, central processing unit (“CPU(s)” and/or “processor(s)” (these terms are used interchangeable throughout the disclosure unless noted to the contrary)) <b>9903</b>, a memory <b>9929</b> (e.g., a read only memory (ROM) <b>9906</b>, a random access memory (RAM) <b>9905</b>, etc.), and/or an interface bus <b>9907</b>, and most frequently, although not necessarily, are all interconnected and/or communicating through a system bus <b>9904</b> on one or more (mother)board(s) <b>9902</b> having conductive and/or otherwise transportive circuit pathways through which instructions (e.g., binary encoded signals) may travel to effectuate communications, operations, storage, etc. The computer systemization may be connected to a power source <b>9986</b>; e.g., optionally the power source may be internal. Optionally, a cryptographic processor <b>9926</b> may be connected to the system bus. In another embodiment, the cryptographic processor, transceivers (e.g., ICs) <b>9974</b>, and/or sensor array (e.g., accelerometer, altimeter, ambient light, barometer, global positioning system (GPS) (thereby allowing MLPO controller to determine its location), gyroscope, magnetometer, pedometer, proximity, ultra-violet sensor, etc.) <b>9973</b> may be connected as either internal and/or external peripheral devices <b>9912</b> via the interface bus I/O <b>9908</b> (not pictured) and/or directly via the interface bus <b>9907</b>. In turn, the transceivers may be connected to antenna(s) <b>9975</b>, thereby effectuating wireless transmission and reception of various communication and/or sensor protocols; for example the antenna(s) may connect to various transceiver chipsets (depending on deployment needs), including: Broadcom® BCM4329FKUBG transceiver chip (e.g., providing 802.11n, Bluetooth 2.1+EDR, FM, etc.); a Broadcom® BCM4752 GPS receiver with accelerometer, altimeter, GPS, gyroscope, magnetometer; a Broadcom® BCM4335 transceiver chip (e.g., providing 2G, 3G, and 4G long-term evolution (LTE) cellular communications; 802.11ac, Bluetooth 4.0 low energy (LE) (e.g., beacon features)); a Broadcom® BCM43341 transceiver chip (e.g., providing 2G, 3G and 4G LTE cellular communications; 802.11 g/, Bluetooth 4.0, near field communication (NFC), FM radio); an Infineon Technologies® X-Gold 618-PMB9800 transceiver chip (e.g., providing 2G/3G HSDPA/HSUPA communications); a MediaTek® MT6620 transceiver chip (e.g., providing 802.11a/ac/b/g/n, Bluetooth 4.0 LE, FM, GPS; a Lapis Semiconductor® ML8511 UV sensor; a maxim integrated MAX44000 ambient light and infrared proximity sensor; a Texas Instruments® WiLink WL1283 transceiver chip (e.g., providing 802.11n, Bluetooth 3.0, FM, GPS); and/or the like. The system clock may have a crystal oscillator and generates a base signal through the computer systemization's circuit pathways. The clock may be coupled to the system bus and various clock multipliers that will increase or decrease the base operating frequency for other components interconnected in the computer systemization. The clock and various components in a computer systemization drive signals embodying information throughout the system. Such transmission and reception of instructions embodying information throughout a computer systemization may be referred to as communications. These communicative instructions may further be transmitted, received, and the cause of return and/or reply communications beyond the instant computer systemization to: communications networks, input devices, other computer systemizations, peripheral devices, and/or the like. It should be understood that in alternative embodiments, any of the above components may be connected directly to one another, connected to the CPU, and/or organized in numerous variations employed as exemplified by various computer systems.

2590The CPU comprises at least one high-speed data processor adequate to execute program components for executing user and/or system-generated requests. The CPU is often packaged in a number of formats varying from large supercomputer(s) and mainframe(s) computers, down to mini computers, servers, desktop computers, laptops, thin clients (e.g., Chromebooks®), netbooks, tablets (e.g., Android®, iPads®, and Windows® tablets, etc.), mobile smartphones (e.g., Android®, iPhones®, Nokia®, Palm® and Windows® phones, etc.), wearable device(s) (e.g., watches, glasses, goggles (e.g., Google Glass), etc.), and/or the like. Often, the processors themselves will incorporate various specialized processing units, such as, but not limited to: integrated system (bus) controllers, memory management control units, floating point units, and even specialized processing sub-units like graphics processing units, digital signal processing units, and/or the like. Additionally, processors may include internal fast access addressable memory, and be capable of mapping and addressing memory <b>9929</b> beyond the processor itself; internal memory may include, but is not limited to: fast registers, various levels of cache memory (e.g., level 1, 2, 3, etc.), RAM, etc. The processor may access this memory through the use of a memory address space that is accessible via instruction address, which the processor can construct and decode allowing it to access a circuit path to a specific memory address space having a memory state. The CPU may be a microprocessor such as: AMD's Athlon®, Duron® and/or Opteron®; Apple's® A series of processors (e.g., A5, A6, A7, A8, etc.); ARM's® application, embedded and secure processors; IBM® and/or Motorola's DragonBall® and PowerPC®; IBM's® and Sony's® Cell processor; Intel's® 80X86 series (e.g., 80386, 80486), Pentium®, Celeron®, Core (2) Duo®, i series (e.g., i3, i5, i7, etc.), Itanium®, Xeon®, and/or XScale®; Motorola's® 680X0 series (e.g., 68020, 68030, 68040, etc.); and/or the like processor(s). The CPU interacts with memory through instruction passing through conductive and/or transportive conduits (e.g., (printed) electronic and/or optic circuits) to execute stored instructions (i.e., program code) according to various data processing techniques. Such instruction passing facilitates communication within the MLPO controller and beyond through various interfaces. Should processing requirements dictate a greater amount speed and/or capacity, distributed processors (e.g., see Distributed MLPO below), mainframe, multi-core, parallel, and/or super-computer architectures may similarly be employed. Alternatively, should deployment requirements dictate greater portability, smaller mobile devices (e.g., Personal Digital Assistants (PDAs)) may be employed.

2591Depending on the particular implementation, features of the MLPO may be achieved by implementing a microcontroller such as CAST's® R8051XC2 microcontroller; Intel's® MCS 51 (i.e., 8051 microcontroller); and/or the like. Also, to implement certain features of the MLPO, some feature implementations may rely on embedded components, such as: Application-Specific Integrated Circuit (“ASIC”), Digital Signal Processing (“DSP”), Field Programmable Gate Array (“FPGA”), and/or the like embedded technology. For example, any of the MLPO component collection (distributed or otherwise) and/or features may be implemented via the microprocessor and/or via embedded components; e.g., via ASIC, coprocessor, DSP, FPGA, and/or the like. Alternately, some implementations of the MLPO may be implemented with embedded components that are configured and used to achieve a variety of features or signal processing.

2592Depending on the particular implementation, the embedded components may include software solutions, hardware solutions, and/or some combination of both hardware/software solutions. For example, MLPO features discussed herein may be achieved through implementing FPGAs, which are a semiconductor devices containing programmable logic components called “logic blocks”, and programmable interconnects, such as the high performance FPGA Virtex® series and/or the low cost Spartan® series manufactured by Xilinx®. Logic blocks and interconnects can be programmed by the customer or designer, after the FPGA is manufactured, to implement any of the MLPO features. A hierarchy of programmable interconnects allow logic blocks to be interconnected as needed by the MLPO system designer/administrator, somewhat like a one-chip programmable breadboard. An FPGA's logic blocks can be programmed to perform the operation of basic logic gates such as AND, and XOR, or more complex combinational operators such as decoders or mathematical operations. In most FPGAs, the logic blocks also include memory elements, which may be circuit flip-flops or more complete blocks of memory. In some circumstances, the MLPO may be developed on FPGAs and then migrated into a fixed version that more resembles ASIC implementations. Alternate or coordinating implementations may migrate MLPO controller features to a final ASIC instead of or in addition to FPGAs. Depending on the implementation all of the aforementioned embedded components and microprocessors may be considered the “CPU” and/or “processor” for the MLPO.

Power Source

2593The power source <b>9986</b> may be of any various form for powering small electronic circuit board devices such as the following power cells: alkaline, lithium hydride, lithium ion, lithium polymer, nickel cadmium, solar cells, and/or the like. Other types of AC or DC power sources may be used as well. In the case of solar cells, in one embodiment, the case provides an aperture through which the solar cell may capture photonic energy. The power cell <b>9986</b> is connected to at least one of the interconnected subsequent components of the MLPO thereby providing an electric current to all subsequent components. In one example, the power source <b>9986</b> is connected to the system bus component <b>9904</b>. In an alternative embodiment, an outside power source <b>9986</b> is provided through a connection across the I/O <b>9908</b> interface. For example, a USB and/or IEEE 1394 connection carries both data and power across the connection and is therefore a suitable source of power.

Interface Adapters

2594Interface bus(ses) <b>9907</b> may accept, connect, and/or communicate to a number of interface adapters, variously although not necessarily in the form of adapter cards, such as but not limited to: input output interfaces (I/O) <b>9908</b>, storage interfaces <b>9909</b>, network interfaces <b>9910</b>, and/or the like. Optionally, cryptographic processor interfaces <b>9927</b> similarly may be connected to the interface bus. The interface bus provides for the communications of interface adapters with one another as well as with other components of the computer systemization. Interface adapters are adapted for a compatible interface bus. Interface adapters variously connect to the interface bus via a slot architecture. Various slot architectures may be employed, such as, but not limited to: Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and/or the like.

2595Storage interfaces <b>9909</b> may accept, communicate, and/or connect to a number of storage devices such as, but not limited to: storage devices <b>9914</b>, removable disc devices, and/or the like. Storage interfaces may employ connection protocols such as, but not limited to: (Ultra) (Serial) Advanced Technology Attachment (Packet Interface) ((Ultra) (Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE), Institute of Electrical and Electronics Engineers (IEEE) 1394, fiber channel, Small Computer Systems Interface (SCSI), Universal Serial Bus (USB), and/or the like.

2596Network interfaces <b>9910</b> may accept, communicate, and/or connect to a communications network <b>9913</b>. Through a communications network <b>9913</b>, the MLPO controller is accessible through remote clients <b>9933</b><i>b </i>(e.g., computers with web browsers) by users <b>9933</b><i>a</i>. Network interfaces may employ connection protocols such as, but not limited to: direct connect, Ethernet (thick, thin, twisted pair 10/100/1000/10000 Base T, and/or the like), Token Ring, wireless connection such as IEEE 802.11a-x, and/or the like. Should processing requirements dictate a greater amount speed and/or capacity, distributed network controllers (e.g., see Distributed MLPO below), architectures may similarly be employed to pool, load balance, and/or otherwise decrease/increase the communicative bandwidth required by the MLPO controller. A communications network may be any one and/or the combination of the following: a direct interconnection; the Internet; Interplanetary Internet (e.g., Coherent File Distribution Protocol (CFDP), Space Communications Protocol Specifications (SCPS), etc.); a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a cellular, WiFi, Wireless Application Protocol (WAP), I-mode, and/or the like); and/or the like. A network interface may be regarded as a specialized form of an input output interface. Further, multiple network interfaces <b>9910</b> may be used to engage with various communications network types <b>9913</b>. For example, multiple network interfaces may be employed to allow for the communication over broadcast, multicast, and/or unicast networks.

2597Input Output interfaces (I/O) <b>9908</b> may accept, communicate, and/or connect to user, peripheral devices <b>9912</b> (e.g., input devices <b>9911</b>), cryptographic processor devices <b>9928</b>, and/or the like. I/O may employ connection protocols such as, but not limited to: audio: analog, digital, monaural, RCA, stereo, and/or the like; data: Apple Desktop Bus (ADB), IEEE 1394a-b, serial, universal serial bus (USB); infrared; Joystick; keyboard; midi; optical; PC AT; PS/2; parallel; radio; touch interfaces: capacitive, optical, resistive, etc. displays; video interface: Apple Desktop Connector (ADC), BNC, coaxial, component, composite, digital, Digital Visual Interface (DVI), (mini) displayport, high-definition multimedia interface (HDMI), RCA, RF antennae, S-Video, VGA, and/or the like; wireless transceivers: 802.11a/ac/b/g/n/x; Bluetooth; cellular (e.g., code division multiple access (CDMA), high speed packet access (HSPA(+)), high-speed downlink packet access (HSDPA), global system for mobile communications (GSM), long term evolution (LTE), WiMax, etc.); and/or the like. One output device may include a video display, which may comprise a Cathode Ray Tube (CRT) or Liquid Crystal Display (LCD) based monitor with an interface (e.g., DVI circuitry and cable) that accepts signals from a video interface, may be used. The video interface composites information generated by a computer systemization and generates video signals based on the composited information in a video memory frame. Another output device is a television set, which accepts signals from a video interface. The video interface provides the composited video information through a video connection interface that accepts a video display interface (e.g., an RCA composite video connector accepting an RCA composite video cable; a DVI connector accepting a DVI display cable, etc.).

2598Peripheral devices <b>9912</b> may be connected and/or communicate to I/O and/or other facilities of the like such as network interfaces, storage interfaces, directly to the interface bus, system bus, the CPU, and/or the like. Peripheral devices may be external, internal and/or part of the MLPO controller. Peripheral devices may include: antenna, audio devices (e.g., line-in, line-out, microphone input, speakers, etc.), cameras (e.g., gesture (e.g., Microsoft Kinect) detection, motion detection, still, video, webcam, etc.), dongles (e.g., for copy protection, ensuring secure transactions with a digital signature, and/or the like), external processors (for added capabilities; e.g., crypto devices <b>528</b>), force-feedback devices (e.g., vibrating motors), infrared (IR) transceiver, network interfaces, printers, scanners, sensors/sensor arrays and peripheral extensions (e.g., ambient light, GPS, gyroscopes, proximity, temperature, etc.), storage devices, transceivers (e.g., cellular, GPS, etc.), video devices (e.g., goggles, monitors, etc.), video sources, visors, and/or the like. Peripheral devices often include types of input devices (e.g., cameras).

2599User input devices <b>9911</b> often are a type of peripheral device <b>512</b> (see above) and may include: card readers, dongles, finger print readers, gloves, graphics tablets, joysticks, keyboards, microphones, mouse (mice), remote controls, security/biometric devices (e.g., fingerprint reader, iris reader, retina reader, etc.), touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, styluses, and/or the like.

2600It should be noted that although user input devices and peripheral devices may be employed, the MLPO controller may be embodied as an embedded, dedicated, and/or monitor-less (i.e., headless) device, wherein access would be provided over a network interface connection.

2601Cryptographic units such as, but not limited to, microcontrollers, processors <b>9926</b>, interfaces <b>9927</b>, and/or devices <b>9928</b> may be attached, and/or communicate with the MLPO controller. A MC68HC16 microcontroller, manufactured by Motorola, Inc.®, may be used for and/or within cryptographic units. The MC68HC16 microcontroller utilizes a 16-bit multiply-and-accumulate instruction in the 16 MHz configuration and requires less than one second to perform a 512-bit RSA private key operation. Cryptographic units support the authentication of communications from interacting agents, as well as allowing for anonymous transactions. Cryptographic units may also be configured as part of the CPU. Equivalent microcontrollers and/or processors may also be used. Other specialized cryptographic processors include: Broadcom's® CryptoNetX and other Security Processors; nCipher's® nShield; SafeNet's® Luna PCI (e.g., 7100) series; Semaphore Communications'® 40 MHz Roadrunner 184; Sun's® Cryptographic Accelerators (e.g., Accelerator 6000 PCIe Board, Accelerator 500 Daughtercard); Via Nano® Processor (e.g., L2100, L2200, U2400) line, which is capable of performing 500+MB/s of cryptographic instructions; VLSI Technology's® 33 MHz 6868; and/or the like.

Memory

2602Generally, any mechanization and/or embodiment allowing a processor to affect the storage and/or retrieval of information is regarded as memory <b>9929</b>. However, memory is a fungible technology and resource, thus, any number of memory embodiments may be employed in lieu of or in concert with one another. It is to be understood that the MLPO controller and/or a computer systemization may employ various forms of memory <b>9929</b>. For example, a computer systemization may be configured wherein the operation of on-chip CPU memory (e.g., registers), RAM, ROM, and any other storage devices are provided by a paper punch tape or paper punch card mechanism; however, such an embodiment would result in an extremely slow rate of operation. In one configuration, memory <b>9929</b> will include ROM <b>9906</b>, RAM <b>9905</b>, and a storage device <b>9914</b>. A storage device <b>9914</b> may be any various computer system storage. Storage devices may include: an array of devices (e.g., Redundant Array of Independent Disks (RAID)); a drum; a (fixed and/or removable) magnetic disk drive; a magneto-optical drive; an optical drive (i.e., Blueray, CD ROM/RAM/Recordable (R)/ReWritable (RW), DVD R/RW, HD DVD R/RW etc.); RAM drives; solid state memory devices (USB memory, solid state drives (SSD), etc.); other processor-readable storage mediums; and/or other devices of the like. Thus, a computer systemization generally requires and makes use of memory.

Component Collection

2603The memory <b>9929</b> may contain a collection of program and/or database components and/or data such as, but not limited to: operating system component(s) <b>9915</b> (operating system); information server component(s) <b>9916</b> (information server); user interface component(s) <b>9917</b> (user interface); Web browser component(s) <b>9918</b> (Web browser); database(s) <b>9919</b>; mail server component(s) <b>9921</b>; mail client component(s) <b>9922</b>; cryptographic server component(s) <b>9920</b> (cryptographic server); the MLPO component(s) <b>9935</b>; and/or the like (i.e., collectively a component collection). These components may be stored and accessed from the storage devices and/or from storage devices accessible through an interface bus. Although unconventional program components such as those in the component collection may be stored in a local storage device <b>9914</b>, they may also be loaded and/or stored in memory such as: peripheral devices, RAM, remote storage facilities through a communications network, ROM, various forms of memory, and/or the like.

Operating System

2604The operating system component <b>9915</b> is an executable program component facilitating the operation of the MLPO controller. The operating system may facilitate access of I/O, network interfaces, peripheral devices, storage devices, and/or the like. The operating system may be a highly fault tolerant, scalable, and secure system such as: Apple's Macintosh OS X (Server) and macOS®; AT&amp;T Plan 9®; Be OS®; Blackberry's QNX®; Google's Chrome®; Microsoft's Windows® 7/8/10; Unix and Unix-like system distributions (such as AT&amp;T's UNIX®; Berkley Software Distribution (BSD)® variations such as FreeBSD®, NetBSD, OpenBSD, and/or the like; Linux distributions such as Red Hat, Ubuntu, and/or the like); and/or the like operating systems. However, more limited and/or less secure operating systems also may be employed such as Apple Macintosh OS® (i.e., versions 1-9), IBM OS/2®, Microsoft DOS®, Microsoft Windows 2000/2003/3.1/95/98/CE/Millenium/Mobile/NT/Vista/XP (Server)®, Palm OS®, and/or the like. Additionally, for robust mobile deployment applications, mobile operating systems may be used, such as: Apple's iOS®; China Operating System COS®; Google's Android®; Microsoft Windows RT/Phone®; Palm's WebOS®; Samsung/Intel's Tizen®; and/or the like. An operating system may communicate to and/or with other components in a component collection, including itself, and/or the like. Most frequently, the operating system communicates with other program components, user interfaces, and/or the like. For example, the operating system may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. The operating system, once executed by the CPU, may enable the interaction with communications networks, data, I/O, peripheral devices, program components, memory, user input devices, and/or the like. The operating system may provide communications protocols that allow the MLPO controller to communicate with other entities through a communications network <b>9913</b>. Various communication protocols may be used by the MLPO controller as a subcarrier transport mechanism for interaction, such as, but not limited to: multicast, TCP/IP, UDP, unicast, and/or the like.

Information Server

2605An information server component <b>9916</b> is a stored program component that is executed by a CPU. The information server may be an Internet information server such as, but not limited to Apache Software Foundation's Apache, Microsoft's Internet Information Server, and/or the like. The information server may allow for the execution of program components through facilities such as Active Server Page (ASP), ActiveX, (ANSI) (Objective-) C (++), C# and/or .NET, Common Gateway Interface (CGI) scripts, dynamic (D) hypertext markup language (HTML), FLASH, Java, JavaScript, Practical Extraction Report Language (PERL), Hypertext Pre-Processor (PHP), pipes, Python, wireless application protocol (WAP), WebObjects®, and/or the like. The information server may support secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), messaging protocols (e.g., America Online (AOL) Instant Messenger (AIM)®, Application Exchange (APEX), ICQ, Internet Relay Chat (IRC), Microsoft Network (MSN) Messenger® Service, Presence and Instant Messaging Protocol (PRIM), Internet Engineering Task Force's® (IETF's) Session Initiation Protocol (SIP), SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE), open XML-based Extensible Messaging and Presence Protocol (XMPP) (i.e., Jabber® or Open Mobile Alliance's (OMA's) Instant Messaging and Presence Service (IMPS)), Yahoo! Instant Messenger® Service, and/or the like. The information server provides results in the form of Web pages to Web browsers, and allows for the manipulated generation of the Web pages through interaction with other program components. After a Domain Name System (DNS) resolution portion of an HTTP request is resolved to a particular information server, the information server resolves requests for information at specified locations on the MLPO controller based on the remainder of the HTTP request. For example, a request such as http://123.124.125.126/myInformation.html might have the IP portion of the request “123.124.125.126” resolved by a DNS server to an information server at that IP address; that information server might in turn further parse the http request for the “/myInformation.html” portion of the request and resolve it to a location in memory containing the information “myInformation.html.” Additionally, other information serving protocols may be employed across various ports, e.g., FTP communications across port <b>21</b>, and/or the like. An information server may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the information server communicates with the MLPO database <b>9919</b>, operating systems, other program components, user interfaces, Web browsers, and/or the like.

2606Access to the MLPO database may be achieved through a number of database bridge mechanisms such as through scripting languages as enumerated below (e.g., CGI) and through inter-application communication channels as enumerated below (e.g., CORBA, WebObjects, etc.). Any data requests through a Web browser are parsed through the bridge mechanism into appropriate grammars as required by the MLPO. In one embodiment, the information server would provide a Web form accessible by a Web browser. Entries made into supplied fields in the Web form are tagged as having been entered into the particular fields, and parsed as such. The entered terms are then passed along with the field tags, which act to instruct the parser to generate queries directed to appropriate tables and/or fields. In one embodiment, the parser may generate queries in SQL by instantiating a search string with the proper join/select commands based on the tagged text entries, wherein the resulting command is provided over the bridge mechanism to the MLPO as a query. Upon generating query results from the query, the results are passed over the bridge mechanism, and may be parsed for formatting and generation of a new results Web page by the bridge mechanism. Such a new results Web page is then provided to the information server, which may supply it to the requesting Web browser.

2607Also, an information server may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.

User Interface

2608Computer interfaces in some respects are similar to automobile operation interfaces. Automobile operation interface elements such as steering wheels, gearshifts, and speedometers facilitate the access, operation, and display of automobile resources, and status. Computer interaction interface elements such as buttons, check boxes, cursors, menus, scrollers, and windows (collectively referred to as widgets) similarly facilitate the access, capabilities, operation, and display of data and computer hardware and operating system resources, and status. Operation interfaces are called user interfaces. Graphical user interfaces (GUIs) such as the Apple's iOS®, Macintosh Operating System's Aqua®; IBM's OS/2®; Google's Chrome® (e.g., and other webbrowser/cloud based client OSs); Microsoft's Windows® varied UIs 2000/2003/3.1/95/98/CE/Millenium/Mobile/NT/Vista/XP (Server) (i.e., Aero, Surface, etc.); Unix's X-Windows (e.g., which may include additional Unix graphic interface libraries and layers such as K Desktop Environment (KDE), mythTV and GNU Network Object Model Environment (GNOME)), web interface libraries (e.g., ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, etc. interface libraries such as, but not limited to, Dojo, jQuery(UI), MooTools, Prototype, script.aculo.us, SWFObject, Yahoo! User Interface®, any of which may be used and) provide a baseline and means of accessing and displaying information graphically to users.

2609A user interface component <b>9917</b> is a stored program component that is executed by a CPU. The user interface may be a graphic user interface as provided by, with, and/or atop operating systems and/or operating environments such as already discussed. The user interface may allow for the display, execution, interaction, manipulation, and/or operation of program components and/or system facilities through textual and/or graphical facilities. The user interface provides a facility through which users may affect, interact, and/or operate a computer system. A user interface may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the user interface communicates with operating systems, other program components, and/or the like. The user interface may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.

Web Browser

2610A Web browser component <b>9918</b> is a stored program component that is executed by a CPU. The Web browser may be a hypertext viewing application such as Apple's (mobile) Safari®, Google's Chrome®, Microsoft Internet Explorer®, Mozilla's Firefox®, Netscape Navigator®, and/or the like. Secure Web browsing may be supplied with 128 bit (or greater) encryption by way of HTTPS, SSL, and/or the like. Web browsers allowing for the execution of program components through facilities such as ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, web browser plug-in APIs (e.g., FireFox®, Safari® Plug-in, and/or the like APIs), and/or the like. Web browsers and like information access tools may be integrated into PDAs, cellular telephones, and/or other mobile devices. A Web browser may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the Web browser communicates with information servers, operating systems, integrated program components (e.g., plug-ins), and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. Also, in place of a Web browser and information server, a combined application may be developed to perform similar operations of both. The combined application would similarly affect the obtaining and the provision of information to users, user agents, and/or the like from the MLPO enabled nodes. The combined application may be nugatory on systems employing Web browsers.

Mail Server

2611A mail server component <b>9921</b> is a stored program component that is executed by a CPU <b>9903</b>. The mail server may be an Internet mail server such as, but not limited to: dovecot, Courier IMAP, Cyrus IMAP, Maildir, Microsoft Exchange, sendmail, and/or the like. The mail server may allow for the execution of program components through facilities such as ASP, ActiveX, (ANSI) (Objective-) C (++), C# and/or .NET, CGI scripts,Java,JavaScript, PERL, PHP, pipes, Python, WebObjects®, and/or the like. The mail server may support communications protocols such as, but not limited to: Internet message access protocol (IMAP), Messaging Application Programming Interface (MAPI)/Microsoft Exchange, post office protocol (POP3), simple mail transfer protocol (SMTP), and/or the like. The mail server can route, forward, and process incoming and outgoing mail messages that have been sent, relayed and/or otherwise traversing through and/or to the MLPO. Alternatively, the mail server component may be distributed out to mail service providing entities such as Google's® cloud services (e.g., Gmail and notifications may alternatively be provided via messenger services such as AOL's Instant Messenger®, Apple's iMessage®, Google Messenger®, SnapChat®, etc.).

2612Access to the MLPO mail may be achieved through a number of APIs offered by the individual Web server components and/or the operating system.

2613Also, a mail server may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses.

Mail Client

2614A mail client component <b>9922</b> is a stored program component that is executed by a CPU <b>9903</b>. The mail client may be a mail viewing application such as Apple Mail®, Microsoft Entourage®, Microsoft Outlook®, Microsoft Outlook Express®, Mozilla®, Thunderbird®, and/or the like. Mail clients may support a number of transfer protocols, such as: IMAP, Microsoft Exchange, POP3, SMTP, and/or the like. A mail client may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the mail client communicates with mail servers, operating systems, other mail clients, and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses. Generally, the mail client provides a facility to compose and transmit electronic mail messages.

Cryptographic Server

2615A cryptographic server component <b>9920</b> is a stored program component that is executed by a CPU <b>9903</b>, cryptographic processor <b>9926</b>, cryptographic processor interface <b>9927</b>, cryptographic processor device <b>9928</b>, and/or the like. Cryptographic processor interfaces will allow for expedition of encryption and/or decryption requests by the cryptographic component; however, the cryptographic component, alternatively, may run on a CPU. The cryptographic component allows for the encryption and/or decryption of provided data. The cryptographic component allows for both symmetric and asymmetric (e.g., Pretty Good Protection (PGP)) encryption and/or decryption. The cryptographic component may employ cryptographic techniques such as, but not limited to: digital certificates (e.g., X.509 authentication framework), digital signatures, dual signatures, enveloping, password access protection, public key management, and/or the like. The cryptographic component will facilitate numerous (encryption and/or decryption) security protocols such as, but not limited to: checksum, Data Encryption Standard (DES), Elliptical Curve Encryption (ECC), International Data Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one way hash operation), passwords, Rivest Cipher (RC5), Rijndael, RSA (which is an Internet encryption and authentication system that uses an algorithm developed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA), Secure Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS), Transport Layer Security (TLS), and/or the like. Employing such encryption security protocols, the MLPO may encrypt all incoming and/or outgoing communications and may serve as node within a virtual private network (VPN) with a wider communications network. The cryptographic component facilitates the process of “security authorization” whereby access to a resource is inhibited by a security protocol wherein the cryptographic component effects authorized access to the secured resource. In addition, the cryptographic component may provide unique identifiers of content, e.g., employing and MD5 hash to obtain a unique signature for a digital audio file. A cryptographic component may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. The cryptographic component supports encryption schemes allowing for the secure transmission of information across a communications network to allow the MLPO component to engage in secure transactions if so desired. The cryptographic component facilitates the secure accessing of resources on the MLPO and facilitates the access of secured resources on remote systems; i.e., it may act as a client and/or server of secured resources. Most frequently, the cryptographic component communicates with information servers, operating systems, other program components, and/or the like. The cryptographic component may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.

The MLPO Database

2616The MLPO database component <b>9919</b> may be embodied in a database and its stored data. The database is a stored program component, which is executed by the CPU; the stored program component portion configuring the CPU to process the stored data. The database may be a fault tolerant, relational, scalable, secure database such as MySQL®, Oracle®, Sybase®, etc. may be used. Additionally, optimized fast memory and distributed databases such as IBM's Netezza®, MongoDB's MongoDB®, opensource Hadoop®, opensource VoltDB, SAP's Hana®, etc. Relational databases are an extension of a flat file. Relational databases consist of a series of related tables. The tables are interconnected via a key field. Use of the key field allows the combination of the tables by indexing against the key field; i.e., the key fields act as dimensional pivot points for combining information from various tables. Relationships generally identify links maintained between tables by matching primary keys. Primary keys represent fields that uniquely identify the rows of a table in a relational database. Alternative key fields may be used from any of the fields having unique value sets, and in some alternatives, even non-unique values in combinations with other fields. More precisely, they uniquely identify rows of a table on the “one” side of a one-to-many relationship.

2617Alternatively, the MLPO database may be implemented using various other data-structures, such as an array, hash, (linked) list, struct, structured text file (e.g., XML), table, and/or the like. Such data-structures may be stored in memory and/or in (structured) files. In another alternative, an object-oriented database may be used, such as Frontier™, ObjectStore, Poet, Zope, and/or the like. Object databases can include a number of object collections that are grouped and/or linked together by common attributes; they may be related to other object collections by some common attributes. Object-oriented databases perform similarly to relational databases with the exception that objects are not just pieces of data but may have other types of capabilities encapsulated within a given object. If the MLPO database is implemented as a data-structure, the use of the MLPO database <b>9919</b> may be integrated into another component such as the MLPO component <b>9935</b>. Also, the database may be implemented as a mix of data structures, objects, and relational structures. Databases may be consolidated and/or distributed in countless variations (e.g., see Distributed MLPO below). Portions of databases, e.g., tables, may be exported and/or imported and thus decentralized and/or integrated.

2618In one embodiment, the database component <b>9919</b> includes several tables <b>9919</b><i>a</i>-<i>z: </i>

2619An accounts table <b>9919</b><i>a </i>includes fields such as, but not limited to: an accountID, accountOwnerID, accountContactID, assetIDs, deviceIDs, paymentIDs, transactionIDs, userIDs, accountType (e.g., agent, entity (e.g., corporate, non-profit, partnership, etc.), individual, etc.), accountCreationDate, accountUpdateDate, accountName, accountNumber, routingNumber, linkWalletsID, accountPrioritAccaountRatio, accountAddress, accountState, accountZIPcode, accountCountry, accountEmail, accountPhone, accountAuthKey, accountIPaddress, accountURLAccessCode, accountPortNo, accountAuthorizationCode, accountAccessPrivileges, accountPreferences, accountRestrictions, and/or the like;

2620A users table <b>9919</b><i>b </i>includes fields such as, but not limited to: a userID, userSSN, taxID, userContactID, accountID, assetIDs, deviceIDs, paymentIDs, transactionIDs, userType (e.g., agent, entity (e.g., corporate, non-profit, partnership, etc.), individual, etc.), namePrefix, firstName, middleName, lastName, nameSuffix, DateOfBirth, userAge, userName, userEmail, userSocialAccountID, contactType, contactRelationship, userPhone, userAddress, userCity, userState, userZIPCode, userCountry, userAuthorizationCode, userAccessPrivilges, userPreferences, userRestrictions, and/or the like (the user table may support and/or track multiple entity accounts on a MLPO);

2621An devices table <b>9919</b><i>c </i>includes fields such as, but not limited to: deviceID, sensorIDs, accountID, assetIDs, paymentIDs, deviceType, deviceName, deviceManufacturer, deviceModel, deviceVersion, deviceSerialNo, deviceIPaddress, deviceMACaddress, device_ECID, deviceUUID, deviceLocation, deviceCertificate, deviceOS, appIDs, deviceResources, deviceSession, authKey, deviceSecureKey, walletAppInstalledFlag, deviceAccessPrivileges, devicePreferences, deviceRestrictions, hardware_config, software_config, storage_location, sensor_value, pin_reading, data length, channel_requirement, sensor_name, sensor_model_no, sensor_manufacturer, sensor_type, sensor_serial_number, sensor_power_requirement, device_power_requirement, location, sensor_associated_tool, sensor_dimensions, device_dimensions, sensor_communications_type, device_communications_type, power_percentage, power_condition, temperature_setting, speed_adjust, hold_duration, part_actuation, and/or the like. Device table may, in some embodiments, include fields corresponding to one or more Bluetooth profiles, such as those published at https://www.bluetooth.org/en-us/specification/adopted-specifications, and/or other device specifications, and/or the like;

2622An apps table <b>9919</b><i>d </i>includes fields such as, but not limited to: appID, appName, appType, appDependencies, accountID, deviceIDs, transactionID, userID, appStoreAuthKey, appStoreAccountID, appStoreIPaddress, appStoreURLaccessCode, appStorePortNo, appAccessPrivileges, appPreferences, appRestrictions, portNum, access_API_call, linked_wallets_list, and/or the like;

2623An assets table <b>9919</b><i>e </i>includes fields such as, but not limited to: assetID, accountID, userID, distributorAccountID, distributorPaymentID, distributorOnwerlD, assetOwnerID, assetType, assetSourceDeviceID, assetSourceDeviceType, assetSourceDeviceName, assetSourceDistributionChannelID, assetSourceDistributionChannelType, assetSourceDistributionChannelName, assetTargetChannelID, assetTargetChannelType, assetTargetChannelName, assetName, assetSeriesName, assetSeriesSeason, assetSeriesEpisode, assetCode, assetQuantity, assetCost, assetPrice, assetValue, assetManufactuer, assetModelNo, assetSerialNo, assetLocation, assetAddress, assetState, assetZIPcode, assetState, assetCountry, assetEmail, assetIPaddress, assetURLaccessCode, assetOwnerAccountID, subscriptionIDs, assetAuthroizationCode, assetAccessPrivileges, assetPreferences, assetRestrictions, assetAPI, assetAPIconnectionAddress, and/or the like;

2624A payments table <b>9919</b><i>f </i>includes fields such as, but not limited to: paymentID, accountID, userID, couponID, couponValue, couponConditions, couponExpiration, paymentType, paymentAccountNo, paymentAccountName, paymentAccountAuthorizationCodes, paymentExpirationDate, paymentCCV, paymentRoutingNo, paymentRoutingType, paymentAddress, paymentState, paymentZIPcode, paymentCountry, paymentEmail, paymentAuthKey, paymentIPaddress, paymentURLaccessCode, paymentPortNo, paymentAccessPrivileges, paymentPreferences, payementRestrictions, and/or the like;

2625An transactions table <b>9919</b><i>g </i>includes fields such as, but not limited to: transactionID, accountID, assetIDs, deviceIDs, paymentIDs, transactionIDs, userID, merchantID, transactionType, transactionDate, transactionTime, transactionAmount, transactionQuantity, transactionDetails, productsList, productType, productTitle, productsSummary, productParamsList, transactionNo, transactionAccessPrivileges, transactionPreferences, transactionRestrictions, merchantAuthKey, merchantAuthCode, and/or the like;

2626An merchants table <b>9919</b><i>h </i>includes fields such as, but not limited to: merchantID, merchantTaxID, merchanteName, merchantContactUserID, accountID, issuerID, acquirerID, merchantEmail, merchantAddress, merchantState, merchantZIPcode, merchantCountry, merchantAuthKey, merchantIPaddress, portNum, merchantURLaccessCode, merchantPortNo, merchantAccessPrivileges, merchantPreferences, merchantRestrictions, and/or the like;

2627An ads table <b>9919</b><i>i </i>includes fields such as, but not limited to: adID, advertiserID, adMerchantID, adNetworkID, adName, adTags, advertiserName, adSponsor, adTime, adGeo, adAttributes, adFormat, adProduct, adText, adMedia, adMedialD, adChannelID, adTagTime, adAudioSignature, adHash, adTemplateID, adTemplateData, adSourceID, adSourceName, adSourceServerIP, adSourceURL, adSourceSecurityProtocol, adSourceFTP, adAuthKey, adAccessPrivileges, adPreferences, adRestrictions, adNetworkXchangeID, adNetworkXchangeName, adNetworkXchangeCost, adNetworkXchangeMetricType (e.g., CPA, CPC, CPM, CTR, etc.), adNetworkXchangeMetricValue, adNetworkXchangeServer, adNetworkXchangePortNumber, publisherID, publisherAddress, publisherURL, publisherTag, publisherIndustry, publisherName, publisherDescription, siteDomain, siteURL, siteContent, siteTag, siteContext, siteImpression, siteVisits, siteHeadline, sitePage, siteAdPrice, sitePlacement, sitePosition, bidID, bidExchange, bidOS, bidTarget, bidTimestamp, bidPrice, bidImpressionID, bidType, bidScore, adType (e.g., mobile, desktop, wearable, largescreen, interstitial, etc.), assetID, merchantID, deviceID, userID, accountID, impressionID, impressionOS, impressionTimeStamp, impressionGeo, impressionAction, impressionType, impressionPublisherID, impressionPublisherURL, and/or the like;

2628A ScenarioResults table <b>9919</b><i>j </i>includes fields such as, but not limited to: simulationID, scenarioID, scenarioTimeframe, scenarioMarketFactorID, scenarioDistributionConfiguration, scenarioTrainedMachineLearningConfigurationData, scenarioSimulatedMarketFactorChange, scenarioAssociatedBusinessCycle, simulationMarketFactorRangeMin, simulationMarketFactorRangeMax, simulationlMarketFactorRangeAverage, and/or the like;

2629A DTEs table <b>9919</b><i>k </i>includes fields such as, but not limited to: DTE_ID, DTE_Type, DTE_LinkedSecurityID, DTE_TrainedConfigurationData, DTE_LinkedsimulationID, and/or the like;

2630An ExpectedReturns table <b>99191</b> includes fields such as, but not limited to: securityID, linkedSimulationID, linkedScenarioID, linkedScenarioSecurityExpectedReturn, and/or the like;

2631A PredefinedScenarios table <b>9919</b><i>m </i>includes fields such as, but not limited to: predefinedScenarioID, customizedMarketFactorID, customizedMarketFactorRangeMin, customizedMarketFactorRangeMax, customizedMarketFactorRangeAverage, predefinedScenarioAssociatedSimulationID, predefinedScenarioAssociatedFilteredMarketScenarios, and/or the like;

2632An asset_sim_wide table <b>9919</b><i>n </i>includes fields such as, but not limited to: asset_id, pricing_dt, sim_id, returns, and/or the like;

2633An asset_measure table <b>9919</b><i>o </i>includes fields such as, but not limited to: asset_id, pricing_dt, sim_id, market_id, measure_name, measure_value, and/or the like;

2634A market_data table <b>9919</b><i>z </i>includes fields such as, but not limited to: market_data_feed_ID, asset_ID, asset_symbol, asset_name, spot_price, bid_price, ask_price, and/or the like; in one embodiment, the market data table is populated through a market data feed (e.g., Bloomberg's PhatPipe®, Consolidated Quote System® (CQS), Consolidated Tape Association® (CTA), Consolidated Tape System® (CTS), Dun &amp; Bradstreet®, OTC Montage Data Feed® (OMDF), Reuter's Tib®, Triarch®, US equity trade and quote market data®, Unlisted Trading Privileges® (UTP) Trade Data Feed® (UTDF), UTP Quotation Data Feed® (UQDF), and/or the like feeds, e.g., via ITC 2.1 and/or respective feed protocols), for example, through Microsoft's® Active Template Library and Dealing Object Technology's real-time toolkit Rtt.Multi.

2635In one embodiment, the MLPO database may interact with other database systems. For example, employing a distributed database system, queries and data access by search MLPO component may treat the combination of the MLPO database, an integrated data security layer database as a single database entity (e.g., see Distributed MLPO below).

2636In one embodiment, user programs may contain various user interface primitives, which may serve to update the MLPO. Also, various accounts may require custom database tables depending upon the environments and the types of clients the MLPO may need to serve. It should be noted that any unique fields may be designated as a key field throughout. In an alternative embodiment, these tables have been decentralized into their own databases and their respective database controllers (i.e., individual database controllers for each of the above tables). Employing various data processing techniques, one may further distribute the databases over several computer systemizations and/or storage devices. Similarly, configurations of the decentralized database controllers may be varied by consolidating and/or distributing the various database components <b>9919</b><i>a</i>-<i>z</i>. The MLPO may be configured to keep track of various settings, inputs, and parameters via database controllers.

2637The MLPO database may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the MLPO database communicates with the MLPO component, other program components, and/or the like. The database may contain, retain, and provide information regarding other nodes and data.

The MLPOs

2638The MLPO component <b>9935</b> is a stored program component that is executed by a CPU. In one embodiment, the MLPO component incorporates any and/or all combinations of the aspects of the MLPO that was discussed in the previous figures. As such, the MLPO affects accessing, obtaining and the provision of information, services, transactions, and/or the like across various communications networks. The features and embodiments of the MLPO discussed herein increase network efficiency by reducing data transfer requirements the use of more efficient data structures and mechanisms for their transfer and storage. As a consequence, more data may be transferred in less time, and latencies with regard to transactions, are also reduced. In many cases, such reduction in storage, transfer time, bandwidth requirements, latencies, etc., will reduce the capacity and structural infrastructure requirements to support the MLPO's features and facilities, and in many cases reduce the costs, energy consumption/requirements, and extend the life of MLPO's underlying infrastructure; this has the added benefit of making the MLPO more reliable. Similarly, many of the features and mechanisms are designed to be easier for users to use and access, thereby broadening the audience that may enjoy/employ and exploit the feature sets of the MLPO; such ease of use also helps to increase the reliability of the MLPO. In addition, the feature sets include heightened security as noted via the Cryptographic components <b>9920</b>, <b>9926</b>, <b>9928</b> and throughout, making access to the features and data more reliable and secure

2639The MLPO transforms machine learning simulation request, decision tree ensembles training request, expected returns calculation request, portfolio construction request, predefined scenario construction request, portfolio returns visualization request inputs, via MLPO components (e.g., MLSSP, DTET, ERC, PC, PSC, SPRV, BPRV, PRV, ARMC), into machine learning simulation response, decision tree ensembles training response, expected returns calculation response, portfolio construction response, predefined scenario construction response, portfolio returns visualization response outputs.

2640The MLPO component enabling access of information between nodes may be developed by employing various development tools and languages such as, but not limited to: Apache® components, Assembly, ActiveX, binary executables, (ANSI) (Objective-) C (++), C# and/or .NET, database adapters, CGI scripts, Java, JavaScript, mapping tools, procedural and object oriented development tools, PERL, PHP, Python, shell scripts, SQL commands, web application server extensions, web development environments and libraries (e.g., Microsoft's® ActiveX; Adobe® AIR, FLEX &amp; FLASH; AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI); MooTools; Prototype; script.aculo.us; Simple Object Access Protocol (SOAP); SWFObject; Yahoo!® User Interface; and/or the like), WebObjects®, and/or the like. In one embodiment, the MLPO server employs a cryptographic server to encrypt and decrypt communications. The MLPO component may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the MLPO component communicates with the MLPO database, operating systems, other program components, and/or the like. The MLPO may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.

Distributed MLPOs

2641The structure and/or operation of any of the MLPO node controller components may be combined, consolidated, and/or distributed in any number of ways to facilitate development and/or deployment. Similarly, the component collection may be combined in any number of ways to facilitate deployment and/or development. To accomplish this, one may integrate the components into a common code base or in a facility that can dynamically load the components on demand in an integrated fashion. As such a combination of hardware may be distributed within a location, within a region and/or globally where logical access to a controller may be abstracted as a singular node, yet where a multitude of private, semiprivate and publicly accessible node controllers (e.g., via dispersed data centers) are coordinated to serve requests (e.g., providing private cloud, semi-private cloud, and public cloud computing resources) and allowing for the serving of such requests in discrete regions (e.g., isolated, local, regional, national, global cloud access).

2642The component collection may be consolidated and/or distributed in countless variations through various data processing and/or development techniques. Multiple instances of any one of the program components in the program component collection may be instantiated on a single node, and/or across numerous nodes to improve performance through load-balancing and/or data-processing techniques. Furthermore, single instances may also be distributed across multiple controllers and/or storage devices; e.g., databases. All program component instances and controllers working in concert may do so through various data processing communication techniques.

2643The configuration of the MLPO controller will depend on the context of system deployment. Factors such as, but not limited to, the budget, capacity, location, and/or use of the underlying hardware resources may affect deployment requirements and configuration. Regardless of if the configuration results in more consolidated and/or integrated program components, results in a more distributed series of program components, and/or results in some combination between a consolidated and distributed configuration, data may be communicated, obtained, and/or provided. Instances of components consolidated into a common code base from the program component collection may communicate, obtain, and/or provide data. This may be accomplished through intra-application data processing communication techniques such as, but not limited to: data referencing (e.g., pointers), internal messaging, object instance variable communication, shared memory space, variable passing, and/or the like. For example, cloud services such as Amazon Data Services®, Microsoft Azure®, Hewlett Packard Helion®, IBM® Cloud services allow for MLPO controller and/or MLPO component collections to be hosted in full or partially for varying degrees of scale.

2644If component collection components are discrete, separate, and/or external to one another, then communicating, obtaining, and/or providing data with and/or to other component components may be accomplished through inter-application data processing communication techniques such as, but not limited to: Application Program Interfaces (API) information passage; (distributed) Component Object Model ((D)COM), (Distributed) Object Linking and Embedding ((D)OLE), and/or the like), Common Object Request Broker Architecture (CORBA), Jini local and remote application program interfaces, JavaScript Object Notation (JSON), Remote Method Invocation (RMI), SOAP, process pipes, shared files, and/or the like. Messages sent between discrete component components for inter-application communication or within memory spaces of a singular component for intra-application communication may be facilitated through the creation and parsing of a grammar. A grammar may be developed by using development tools such as lex, yacc, XML, and/or the like, which allow for grammar generation and parsing capabilities, which in turn may form the basis of communication messages within and between components.

2645For example, a grammar may be arranged to recognize the tokens of an HTTP post command, e.g.: <ul id="ul0428" list-style="none"><li id="ul0428-0001" num="0000"><ul id="ul0429" list-style="none"><li id="ul0429-0001" num="2646">w3c -post http:// . . . Value1</li></ul></li></ul>

2647where Value1 is discerned as being a parameter because “http://” is part of the grammar syntax, and what follows is considered part of the post value. Similarly, with such a grammar, a variable “Value1” may be inserted into an “http://” post command and then sent. The grammar syntax itself may be presented as structured data that is interpreted and/or otherwise used to generate the parsing mechanism (e.g., a syntax description text file as processed by lex, yacc, etc.). Also, once the parsing mechanism is generated and/or instantiated, it itself may process and/or parse structured data such as, but not limited to: character (e.g., tab) delineated text, HTML, structured text streams, XML, and/or the like structured data. In another embodiment, inter-application data processing protocols themselves may have integrated parsers (e.g., JSON, SOAP, and/or like parsers) that may be employed to parse (e.g., communications) data. Further, the parsing grammar may be used beyond message parsing, but may also be used to parse: databases, data collections, data stores, structured data, and/or the like. Again, the desired configuration will depend upon the context, environment, and requirements of system deployment.

2648For example, in some implementations, the MLPO controller may be executing a PHP script implementing a Secure Sockets Layer (“SSL”) socket server via the information server, which listens to incoming communications on a server port to which a client may send data, e.g., data encoded in JSON format. Upon identifying an incoming communication, the PHP script may read the incoming message from the client device, parse the received JSON-encoded text data to extract information from the JSON-encoded text data into PHP script variables, and store the data (e.g., client identifying information, etc.) and/or extracted information in a relational database accessible using the Structured Query Language (“SQL”). An exemplary listing, written substantially in the form of PHP/SQL commands, to accept JSON-encoded input data from a client device via an SSL connection, parse the data to extract variables, and store the data to a database, is provided below:

0000<tables id="TABLE-US-00096" num="00096"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

2649Also, the following resources may be used to provide example embodiments regarding SOAP parser implementation:

0000<tables id="TABLE-US-00097" num="00097"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>http://www.xav.com/perl/site/lib/SOAP/Parser.html </entry></row><row><entry>http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/</entry></row><row><entry>com.ibm.IBMDI.doc/referenceguide295.htm</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> and other parser implementations:

0000<tables id="TABLE-US-00098" num="00098"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/</entry></row><row><entry>com.ibm.IBMDI.doc/referenceguide259.htm</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> all of which are hereby expressly incorporated by reference.

2650In order to address various issues and advance the art, the entirety of this application for Machine Learning Portfolio Simulating and Optimizing Apparatuses, Methods and Systems (including the Cover Page, Title, Headings, Field, Background, Summary, Brief Description of the Drawings, Detailed Description, Claims, Abstract, Figures, Appendices, and otherwise) shows, by way of illustration, various embodiments in which the claimed innovations may be practiced. The advantages and features of the application are of a representative sample of embodiments only, and are not exhaustive and/or exclusive. They are presented only to assist in understanding and teach the claimed principles. It should be understood that they are not representative of all claimed innovations. As such, certain aspects of the disclosure have not been discussed herein. That alternate embodiments may not have been presented for a specific portion of the innovations or that further undescribed alternate embodiments may be available for a portion is not to be considered a disclaimer of those alternate embodiments. It will be appreciated that many of those undescribed embodiments incorporate the same principles of the innovations and others are equivalent. Thus, it is to be understood that other embodiments may be utilized and functional, logical, operational, organizational, structural and/or topological modifications may be made without departing from the scope and/or spirit of the disclosure. As such, all examples and/or embodiments are deemed to be non-limiting throughout this disclosure. Further and to the extent any financial and/or investment examples are included, such examples are for illustrative purpose(s) only, and are not, nor should they be interpreted, as investment advice. Also, no inference should be drawn regarding those embodiments discussed herein relative to those not discussed herein other than it is as such for purposes of reducing space and repetition. For instance, it is to be understood that the logical and/or topological structure of any combination of any program components (a component collection), other components, data flow order, logic flow order, and/or any present feature sets as described in the figures and/or throughout are not limited to a fixed operating order and/or arrangement, but rather, any disclosed order is exemplary and all equivalents, regardless of order, are contemplated by the disclosure. Similarly, descriptions of embodiments disclosed throughout this disclosure, any reference to direction or orientation is merely intended for convenience of description and is not intended in any way to limit the scope of described embodiments. Relative terms such as “lower”, “upper”, “horizontal”, “vertical”, “above”, “below”, “up”, “down”, “top” and “bottom” as well as derivative thereof (e.g., “horizontally”, “downwardly”, “upwardly”, etc.) should not be construed to limit embodiments, and instead, again, are offered for convenience of description of orientation. These relative descriptors are for convenience of description only and do not require that any embodiments be constructed or operated in a particular orientation unless explicitly indicated as such. Terms such as “attached”, “affixed”, “connected”, “coupled”, “interconnected”, and similar may refer to a relationship wherein structures are secured or attached to one another either directly or indirectly through intervening structures, as well as both movable or rigid attachments or relationships, unless expressly described otherwise. Furthermore, it is to be understood that such features are not limited to serial execution, but rather, any number of threads, processes, services, servers, and/or the like that may execute asynchronously, concurrently, in parallel, simultaneously, synchronously, and/or the like are contemplated by the disclosure. As such, some of these features may be mutually contradictory, in that they cannot be simultaneously present in a single embodiment. Similarly, some features are applicable to one aspect of the innovations, and inapplicable to others. In addition, the disclosure includes other innovations not presently claimed. Applicant reserves all rights in those presently unclaimed innovations including the right to claim such innovations, file additional applications, continuations, continuations in part, divisions, and/or the like thereof. As such, it should be understood that advantages, embodiments, examples, functional, features, logical, operational, organizational, structural, topological, and/or other aspects of the disclosure are not to be considered limitations on the disclosure as defined by the claims or limitations on equivalents to the claims. It is to be understood that, depending on the particular needs and/or characteristics of a MLPO individual and/or enterprise user, database configuration and/or relational model, data type, data transmission and/or network framework, syntax structure, and/or the like, various embodiments of the MLPO, may be implemented that allow a great deal of flexibility and customization. For example, aspects of the MLPO may be adapted for derivatives. While various embodiments and discussions of the MLPO have included machine learning and database systems, however, it is to be understood that the embodiments described herein may be readily configured and/or customized for a wide variety of other applications and/or implementations.