Topic
How authorised broker API access works under the framework, and why the weekly limit on changing an address is an architectural constraint.
3 pieces published on this topic · Updated
Most teams read the static IP requirement as a configuration detail and discover late that it behaves like a licence. A client's mapped addresses may be updated at most once per calendar week, which removes the ability to change an address reactively. So any failover design that assumes an address can be re-registered when something breaks at 09:20 does not hold up against the rule.
The intended answer is to register a secondary address for redundancy, in advance, while nothing is broken. It is permitted, it costs nothing, and it is the difference between an outage that fails over and an outage that lasts until the next calendar week.
The access model around it rules out several patterns that were common before. Per-user keys rule out one shared integration credential across a vendor's customers. OAuth rules out storing a customer's login. And whitelisting makes network position part of the authorisation decision rather than possession of a secret alone. Which is also why deployment model and compliance posture cannot usefully be discussed separately: where a platform runs decides whose egress addresses are being whitelisted.
Engineering deep-dives covering this topic.
Who registers the algorithm, whose static IP it is, and who carries the liability, answered from the circulars, with every reference attached.
The retention obligation, the fields an inspection actually asks for, and why "comprehensive logging" is not an answer to the question.
How authorised API access works under the framework, and why the once-per-calendar-week limit on changing an IP breaks naive failover designs.
Describe a strategy in plain language, backtest it against historical data, and paper trade it before any capital is committed.
