Starling Aegistra processes market data in real time to generate allocation recommendations and control the risk of each position. Each execution is recorded in a publicly accessible log, verifiable by third parties without depending on internal reports.
Analysis load distribution by module (last 24h, structure example)
The goal is not to replace investor judgment, but to separate data collection and processing—tasks that require constant presence—from strategic decision making, which can be executed from any location with a stable connection.
The architecture separates functions so that a failure or update in one module does not compromise the others. This also facilitates external technical review, module by module.
Statistical and machine learning models estimate probable movement ranges for liquid assets, with configurable short and medium-term horizons.
Continuous calculation of potential drawdown and correlation between positions, with automatic limits that block orders outside of user-defined parameters.
Rebalancing suggestions based on stated volatility goals, not aggressive return maximization without control.
Notifications when a variable exceeds predefined thresholds, without generating noise due to common minor market fluctuations.
Web terminal accessible from any time zone, with session synchronization to continue the analysis from different devices.
Each executed decision is stamped with a timestamp and verification hash, which can be consulted in the public log described below.
The performance log is available to any registered user. Not only the favorable periods are published: the record includes both the operations that met the projection and those that did not.
Representation of the panel structure available after registration. The exact values depend on the period consulted within the live log.
Each executed recommendation generates a unique identifier and timestamp before the market outcome is known. This prevents rewriting the history once published.
The risk calculation module code has been documented for review by users with technical training. The user is not required to trust the result without being able to examine the process.
| Date | Module | Result | Hash |
|---|---|---|---|
| — | Prediction | Accomplished | a1f3…c9 |
| — | Risk | Within limit | 7b02…e4 |
| — | Optimization | Not fulfilled | f45d…1a |
Example of the column structure of the public log. The actual dates and values are consulted within the terminal.
Each additional module introduces an additional error surface. That is why the system prioritizes a small number of well-audited components over an accumulation of poorly tested functions.
The user sets the maximum acceptable risk before activating any module.
Recommendations are tested against historical data before being applied live.
No order is sent without explicit confirmation from the user.
The result is compared with the original projection and documented.
The system does not seek to eliminate market uncertainty, something that no model can honestly guarantee. Instead, it limits the impact of an adverse scenario through three mechanisms: maximum exposure per asset, maximum correlation between open positions, and a loss threshold that stops new recommendations until manual review.
This approach reduces reliance on intuition in times of high volatility, which is precisely when it is most difficult to maintain cool judgment from anywhere in the world.
The interface was designed assuming variable connections and frequent time zone changes. Sessions are synchronized between devices and critical alerts are prioritized over the usual information noise of the markets.
Starling Aegistra is not a substitute for the user's financial knowledge: it structures the information so that that knowledge is applied with less friction and less screen time.
It is not a requirement. The terminal presents the recommendations with their justification summarized in clear language. The technical detail of the model is available for anyone who wants to review it, but it is not mandatory to operate.
It means that the record of executed decisions, with their subsequent results, can be consulted within the platform without depending on a summary prepared by the team itself. The identifier and timestamp are generated before the outcome is known.
No. No predictive model can guarantee market results. The system is designed to structure decision making and limit risk, not to eliminate the possibility of loss.
Yes. Access is through a browser and the session remains synchronized between devices. A stable internet connection is only required when reviewing or executing a decision.
The user manually configures the maximum exposure per asset and per portfolio before activating any module. These limits can be adjusted at any time from the terminal.
Account creation requires standard identity verification. No payment information is requested to access the public log.