MAYBANK Data Center Co-Location has to prove whether marketed data-centre capacity can survive power and carrier constraints

Summary

• APNIC records AS150124 as MAYBANK-DC-AWN-AS-AP, with remarks naming "MAYBANK Data Center (Co-Location)" and a Pathum Thani address at 91 moo 12 Klongnung Klongluang. The registrant entity carries the Maybank-labelled name, while administrative, technical and abuse contacts sit with Advanced Wireless Network, an AIS group network operator.
• The current routing evidence is negative. RIPEstat's AS overview marked AS150124 as not announced on 12 July 2026, and its routing-status view showed zero IPv4 prefixes, zero IPv6 prefixes and zero current observed neighbours.
• The historical route was narrow but real. RIPEstat routing history saw AS150124 originate 110.49.10.0/24 from August 2022 until July 2024, and the current route-origin validation check still returned a valid authorisation for AS150124 and that /24.
• Maybank Securities Thailand's own public reporting makes the resilience question material. Its 2025 One Report describes preparations for business continuity, disaster recovery, backup systems and separated data-centre arrangements. Those disclosures support the importance of a secondary operating site, not the live capacity or topology of AS150124.
• The network evidence grade is Weak. There is a credible registration and a historical Maybank-labelled routed edge, but no current public route, no published Maybank facility capacity, no disclosed A/B power design, no generator runtime, no cooling redundancy, no carrier-meet evidence and no customer failover result.

The first conclusion has to be a downgrade

MAYBANK Data Center Co-Location sounds like a defined physical asset. It has a name, an ASN, a country, a facility-style address and a known telecom sponsor. In a stronger data-centre profile, those signals would be the beginning of a capacity analysis: who operates the room, how much power is commissioned, which carriers enter, what workloads sit there, and how failover behaves when one dependency is removed. Here, the public record does not support that confident sequence.

The APNIC autonomous-system record is precise about the registered identity. It names AS150124 as MAYBANK-DC-AWN-AS-AP, gives Thailand as the country, lists active registry status, and includes description remarks for "MAYBANK Data Center (Co-Location)" at 91 moo 12 Klongnung Klongluang Pathumtani 12120. It also shows registration in July 2022 and a later change in September 2023. Those facts are enough to treat the entity as an observable infrastructure subject rather than a vague commercial phrase.

But a registry entity is not a facility audit. It says that an ASN was delegated, named and maintained in a public number-resource database. It does not prove that the route is currently announced, that racks are in service, that a Maybank application depends on the site, or that a customer could buy capacity there. It does not identify utility feeds, generator autonomy, cooling topology, fire controls, meet-me diversity or maintenance practice.

The current control-plane evidence is even more limiting. RIPEstat's 12 July 2026 snapshot says AS150124 is not announced. The routing-status view shows no IPv4 or IPv6 announced space and no observed neighbours. That does not mean the data-centre arrangement has been dismantled. It may mean the public ASN is dormant while services use provider-addressed space, private connectivity, another Maybank network, another AIS service, or a managed disaster-recovery design that does not appear in the global BGP table. Yet it does mean that readers should not treat AS150124 as a live internet edge today.

That distinction is the whole article. The Maybank-labelled record matters because financial-sector continuity depends on physical facilities and network recovery. It does not become proof of current survivable capacity just because the label says co-location. The right posture is conservative: register the signal, explain the plausible operating boundary, and require live evidence before turning it into an assurance claim.

What the registered asset actually says

The public registration points in two directions at once. One direction is Maybank. The registrant entity record, ORG-MDC4-AP, is named "MAYBANK Data Center (Co-Location)" and lists AS150124 under that entity. The autonomous-system remarks repeat the Maybank-labelled facility description and Pathum Thani address. The ASN name itself contains both "MAYBANK-DC" and "AWN".

The other direction is Advanced Wireless Network. The administrative and technical contact on the AS record is AWNC1-AP, the Advanced Wireless Network company contact. The abuse contact is IRT-AWN-CO-LTD-TH, whose address and email sit inside AIS/AWN contact infrastructure and whose abuse mailbox was validated by APNIC in February 2026. The 110.49.0.0/16 network record that historically contained the AS150124 /24 is also allocated to Advanced Wireless Network.

That split does not weaken the record. It makes the operating model clearer. The Maybank-labelled function appears to have been placed inside, or at least routed through, an AIS/AWN network-resource environment. That is consistent with a co-location or managed connectivity arrangement in which a financial customer has a named ASN while the telecom operator maintains registry contacts, route objects or address resources. It is not the same thing as a Maybank-owned standalone carrier-neutral facility.

Responsibility therefore has to be unbundled. If a rack or logical edge existed under this arrangement, Maybank or its Thai securities affiliate might own the application, data and continuity requirement. AWN or AIS might own the address resource, BGP handoff, facility access, cross-connect, remote support or upstream routing. A building or data-centre operator might own power, cooling, fire systems and physical security. A customer or regulator would need those roles in writing.

Public records do not expose that responsibility matrix. The SET factsheet for MST identifies Maybank Securities Thailand as a securities company, with a Bangkok business address at the offices at Central World, and links to the company's annual report. The SEC publication page lists recent filings for Maybank Securities Thailand. Those corporate records help explain why resilient infrastructure matters, but they do not say that AS150124 is used by every trading, settlement, risk or client-facing system.

The article therefore treats MAYBANK Data Center Co-Location as a registered infrastructure signal around an existing financial-market company, not as a verified public product. The burden of proof remains on current operating evidence.

Pathum Thani is a facility clue, not a site certificate

The address in the APNIC remarks is specific enough to matter: 91 moo 12 Klongnung Klongluang Pathumtani 12120. Public facility directories associate similar wording with AIS's Tellus data-centre campus in Pathum Thani. PeeringDB's Tellus listing places Tellus in Khlong Nueng, Khlong Luang, Pathum Thani and shows it as a data-centre facility entry. Data Center Map's Tellus entry also identifies AIS Data Center Tellus in the Bangkok market, while its specification page describes a purpose-built carrier facility.

Those sources help interpret the APNIC address. They do not certify that the Maybank-labelled ASN still terminates in a specific rack, cage, room or customer suite. Facility directories are useful market directories, not audit reports. They can confirm that a named data-centre site exists and that the address is plausible. They cannot prove customer placement, installed load, contract term, operational status or the exact demarcation between Maybank and AIS.

That caveat is important because location can be misunderstood. A Pathum Thani data-centre address is not the same as a complete map of application placement. A securities company can use a co-located edge at one site, a head-office application layer in Bangkok, a backup copy in another province, cloud services outside Thailand, exchange connectivity through private circuits, and management systems through a vendor. A visible ASN might carry only one slice of that design.

The APNIC record still has operational value. It narrows the geography from "Thailand" to a Pathum Thani data-centre context. Pathum Thani sits in the greater Bangkok economic and infrastructure region, where connectivity to financial institutions, telecom carriers and enterprise customers is practical. It is also close enough to the Bangkok office environment that the site could support a disaster-recovery or secondary operating function without being a different national market.

The question is whether the geographic separation is sufficient for the failure being tested. A site north of Bangkok may reduce exposure to a head-office outage. It does not automatically escape the same metro fibre corridors, regional power constraints, monsoon flooding exposure, supplier staffing limits or telecom maintenance windows. Separation has to be tested against named hazards: a Bangkok building outage, a metropolitan fibre cut, a grid disturbance, a flood event, a data-centre plant failure or a provider routing withdrawal.

The strongest public conclusion is modest. The facility clue is credible enough to ask facility-grade questions. It is not enough to answer them.

Maybank's own reporting makes continuity material

Maybank Securities Thailand is not a low-stakes website operator. The SET factsheet classifies MST as a securities company, and the company's public reports describe a business tied to securities brokerage, derivative brokerage, underwriting, investment advisory, securities borrowing and lending, and related financial services. For such a firm, infrastructure failure is not only an inconvenience. It can affect order entry, market data, client access, risk controls, settlement support, call-centre operation, regulatory reporting and internal supervision.

The company's 2025 One Report is therefore central context. It describes information-technology risk controls, business-continuity preparation, disaster-recovery planning, backup arrangements and separated data-centre preparation. The point is not to quote the report as a guarantee. The point is that the company itself recognises continuity and technology risk as board-level and operating concerns.

Those disclosures support why an entity named "MAYBANK Data Center (Co-Location)" belongs in a financial infrastructure watchlist. A co-located data-centre arrangement can be the physical answer to several continuity requirements. It can house backup servers, replicated databases, security appliances, trading support systems, market-connectivity equipment or emergency workplace infrastructure. It can also provide network independence from a head office or primary data room.

But the report does not convert AS150124 into a verified service. It does not publish the ASN, name the Pathum Thani facility, state the power topology, list carriers, quantify recovery time, or disclose the result of a failover test using the Maybank-labelled edge. It is evidence that disaster recovery matters and that Maybank has controls. It is not evidence that this particular registered ASN is currently carrying a recoverable workload.

That gap is normal in financial services. Firms rarely disclose exact architecture because it can create security risk. The answer is not to demand sensitive diagrams in public. The answer is to distinguish public assurance from private verification. Public readers can verify the registration and routing state. Regulators, auditors and enterprise counterparties can verify the confidential materials: site list, test report, circuit inventory, recovery scripts, data-replication status, power test record and supplier responsibility matrix.

The public article can only do the first half. It can identify the unresolved questions and explain why they matter.

The disappeared route is the biggest public warning

AS150124 was not always quiet. RIPEstat's routing-history data shows the ASN originating 110.49.10.0/24 from August 2022 into July 2024. The route was visible to a substantial number of full-feed peers for most of that interval. The BGP state on 5 July 2024 showed paths to that /24 through AS19551 immediately before AS150124, and the ASN-neighbours view for 1 July 2024 likewise saw one upstream-side neighbour.

That history proves that AS150124 was more than a dormant label when first registered. It had a globally visible IPv4 origin for nearly two years. But the same history makes the 2026 absence significant. If a Maybank-labelled data-centre edge once originated a dedicated /24 and no longer does, analysts need to know why.

There are benign explanations. The workload may have migrated to private MPLS, SD-WAN, exchange circuits or provider NAT. The ASN may have been used for a temporary project, test environment, migration phase or disaster-recovery setup that later changed. The route may be intentionally withdrawn because a backup site should not advertise until invoked. AWN may be carrying services under its own ASN. Maybank may use a different public edge for current services.

There are also resilience-relevant explanations. The project may be inactive. The address plan may have been consolidated. A vendor or contract may have changed. A secondary edge may have failed a business case. A disaster-recovery design may exist but not be externally reachable until manual action. A backup route that is not regularly announced can still work, but it has to be tested differently from an always-on path.

Public BGP cannot choose among those explanations. It can only show that the observable internet-facing claim has gone dark. That is why the correct evidence grade is weak even though the registration is active. A live route can be tested for reachability, neighbours, origin validation and propagation. A dormant route can be tested only by private activation records, change logs, supplier commitments and failover exercises.

If the Pathum Thani co-location arrangement is meant as a warm or cold recovery site, the key question becomes activation. Who can announce the prefix? What approval is required? How long does propagation take? Which firewall policies and DNS records change? How often has the procedure been run under audit? A route absent from the live internet can still be part of a recovery plan, but it cannot be assumed to recover without a recent test.

Valid origin authorization is useful but not enough

One bright spot in the public record is route-origin validation. RIPEstat's current validation check for AS150124 and 110.49.10.0/24 returns a valid authorisation for that origin and prefix, with maximum length /24. That means the visible routing-security control for the historical route is not simply missing. If AS150124 re-originated that /24 under the same authorization, validators should be able to treat the origin as expected.

That is meaningful, especially for a financial-sector edge. Route-origin authorization reduces one common form of accidental or malicious route-origin ambiguity. It helps upstreams and networks filter announcements that claim the wrong origin ASN. It also signals that someone has maintained at least one routing-security artefact after the live route disappeared.

But RPKI is not a recovery plan. A valid origin says that a specific ASN is authorised to originate a specific prefix. It does not prove that a BGP session exists, that the route will be accepted by every upstream, that firewalls and applications are ready, that the handoff has power, or that the path has capacity during a disaster. It does not secure the full AS path. It does not prevent all route leaks. It does not prove DNS, certificates, authentication, market links or customer portals will point to the recovered service.

It also raises a practical question. If the route is withdrawn but the authorization remains valid, is the prefix held in reserve for disaster recovery? Is it a legacy artefact? Is it part of an internal activation playbook? Each answer changes the interpretation. A deliberately dormant, pre-authorised prefix can be a sensible standby design if tested. A forgotten authorization attached to an unused route is a weaker stewardship signal.

The buyer or auditor should therefore ask for three items. First, a current route object and ROA inventory tied to the recovery design. Second, the last date on which AS150124 originated 110.49.10.0/24 in a controlled test. Third, evidence that dependent systems were reachable through that route, not merely that BGP converged.

Routing security removes one uncertainty. It leaves the physical and operational questions untouched.

Co-location changes the responsibility boundary

The label "co-location" is deceptively simple. At the rack level it means equipment is placed in someone else's facility. At the risk level it means ownership is split. A customer may own servers, appliances, security devices and data. The facility operator may own power, cooling, fire systems, physical access and cross-connects. A carrier may own fibre, handoff equipment and route policy. A managed-service provider may own monitoring or remote operation.

The AS150124 registration suggests exactly that split. Maybank appears in the asset label; AWN appears in technical administration; the Pathum Thani address points toward an AIS data-centre environment. A failure analysis has to respect those boundaries. If a utility feed fails, the facility operator is central. If a route fails, AWN and upstream routing matter. If an application fails, Maybank or its application vendor may own restoration. If customer communication fails, the business-continuity team matters.

This is why a public ASN cannot carry all assurance. Suppose the co-located equipment is powered by dual feeds. That is useful only if the two feeds are separately distributed, monitored and maintained, and if the customer devices are actually dual-corded. Suppose the facility has multiple carrier options. That is useful only if the Maybank deployment has contracted diverse handoffs and edge equipment. Suppose the data centre has robust generators. That is useful only if the reserved load includes the Maybank suite and the cooling needed to keep it online.

The public facility context should therefore be read as a set of questions, not a set of inherited guarantees. AIS may operate strong data-centre infrastructure. TH-IX and facility directories may show interconnection in the ecosystem. None of that proves the Maybank deployment bought, configured and tested the relevant resilience features.

Co-location also changes incident communications. During a fault, Maybank may have to coordinate among its own technology team, AIS/AWN network staff, facility operations, exchange or market-connection providers, application vendors and regulators. Recovery can be delayed not by one failed device but by unclear authority: who can approve a route change, pull a cable, enter a cage, reboot an appliance, restore a database or notify clients.

The evidence that would strengthen the record is not necessarily public rack detail. A redacted responsibility matrix would be enough: which party owns power, cooling, network edge, route authorization, remote hands, backup storage, failover decision and customer notice. Without that matrix, the Maybank-labelled co-location record remains a pointer to shared infrastructure rather than a proven operating service.

Power is the first physical constraint

Data-centre resilience begins with electricity. For a financial workload, an outage does not need to last hours to matter. A short interruption can break sessions, freeze trading interfaces, delay reconciliation, interrupt risk checks or force a manual procedure. A longer interruption can exhaust UPS capacity, test generator start, test fuel logistics and expose whether the secondary site can operate independently of the primary site.

The APNIC record does not publish any power facts. It does not say whether the Maybank deployment receives A and B feeds, how those feeds are distributed, what load is reserved, whether there is customer metering, or whether any single breaker, transfer switch, UPS module, generator output or power distribution unit remains common. Facility marketing for the broader AIS environment may describe enterprise data-centre capability, but a customer-specific deployment still needs its own power allocation and failover test.

Thailand's data-centre growth makes this question sharper. The Board of Investment has highlighted large cloud and data-centre investment interest in Thailand, and the power implications of that demand are now part of the market story. Even if the Maybank co-location footprint is small, it competes for the same utility reliability, generator maintenance, electrical contractors and expansion headroom that support larger sites.

Power capacity also has three different meanings. Installed capacity is the equipment nameplate and utility allocation. Sellable capacity is what a facility is willing to contract. Recoverable capacity is what remains after one utility feed, UPS element, generator component or distribution path is unavailable. Customers care about the third number during a fault. Public records for AS150124 do not disclose any of the three.

The most valuable power evidence would be ordinary operating material: a recent load test, generator start and transfer record, fuel runtime at committed load, UPS battery health, A/B distribution diagram, maximum reserved rack draw and incident history. A financial customer should also ask whether backup connectivity, monitoring, authentication and market links remain powered during the same event. Keeping a server energised is not enough if the network edge, DNS, identity service or exchange connection fails.

Until that evidence exists, the phrase data centre should not be used as a synonym for fault-tolerant capacity.

Cooling is the second capacity limit

Every powered server becomes heat. Cooling determines how much of a rack's theoretical electrical capacity can be used safely, and it determines how long a room can survive when mechanical equipment is impaired. Public AS and facility records say nothing about the cooling assigned to the Maybank-labelled deployment.

That omission matters because co-location buyers often inspect network and power first, then assume cooling belongs to the building. It does, but the customer's load still has local behaviour. Dense security appliances, storage arrays, trading gateways, database servers and backup infrastructure can create hot spots. A modest cabinet can be safe at normal load and vulnerable during recovery if extra systems are started, replication catches up, or both primary and recovery tasks run in the same space.

Cooling resilience has several layers. The facility needs enough cooling units or chilled-water capacity. Airflow must reach the cabinet inlets. The cooling plant must be powered during generator operation. Control systems and sensors must function. Maintenance must be possible without reducing safe capacity below the committed load. None of this can be inferred from an ASN label or a facility directory entry.

There is also a recovery sequencing problem. In a disaster-recovery event, the backup site may see a load pattern it does not normally carry. Systems that are idle, warm or lightly used can become active at once. Database replication may surge. Users may shift to emergency access paths. Security inspection may become heavier. If the Maybank site is normally quiet, a live failover test is the only way to show that cooling headroom exists when it matters.

The right evidence is practical and recent: cabinet inlet temperatures at normal and recovery load, alarms, environmental thresholds, cooling-unit-loss tests, maintenance records and the result of a failover exercise run during realistic ambient conditions. The public record reviewed here contains none of those. That absence does not prove weakness inside the facility. It prevents public confidence.

Carrier meet and exchange context are useful but incomplete

Pathum Thani's value is not only power and real estate. It is also access to carriers, exchange points and enterprise networks serving Bangkok's financial and commercial core. AIS's data-centre material, PeeringDB facility records and the TH-IX factsheet place the broader facility ecosystem inside Thailand's interconnection market. That makes the address plausible for a financial backup or co-location site.

For AS150124 itself, though, current public interconnection is absent. The ASN has no current RIPEstat neighbours. The last historical public route had one observed upstream-side neighbour in the July 2024 RIPEstat neighbour view, and the path immediately before AS150124 in many BGP-state samples was AS19551. That is route evidence, not a carrier inventory. It does not identify fibre entrances, contracted ports, physical diversity or customer failover capacity.

Two distinctions are crucial. First, facility richness does not automatically pass through to a customer cage. A building can host many carriers while one customer buys one handoff. Second, public BGP diversity is not the same as physical diversity. A route can appear through one AS path while underlying fibre, cross-connects, powered equipment or provider relationships are more complex. Conversely, a private network can be highly resilient without public BGP at all.

For a financial workload, the relevant network question is service-specific. Which circuits carry market access, client portals, order routing, management access, monitoring, backups and staff connectivity? Which of those paths enter the facility separately? Which have separate edge devices and power domains? Which can carry full recovery traffic if the primary path fails? Which have been tested during a maintenance window?

AS150124's current silence means the public cannot run those checks externally. A buyer can ask for route-monitoring reports, traceroute records, circuit diagrams and failover test results. A public reader can only say that no live public path is visible now and that the historical route does not prove present carrier resilience.

That is why "Peering and transit" remains an evidence-supported topic, but a weakly evidenced one for this entity. The interconnection question is central. The public answer is incomplete.

Installed capacity and usable capacity are not the same

The article title asks whether marketed data-centre capacity can survive constraints. In this case the word "marketed" has to be handled carefully, because the public evidence for a Maybank-labelled data-centre asset is mostly registry and corporate-continuity material, not a product catalogue. There is no reviewed public page offering racks, power blocks, cross-connects or managed colocation under the Maybank name.

If the asset is an internal or affiliated recovery site, the same installed-versus-usable distinction still applies. Installed capacity is the equipment, circuits and facility support physically present. Usable capacity is what can take real traffic without violating security, performance or operating limits. Recoverable capacity is what can take that traffic after a defined failure removes one dependency.

The public record cannot measure any of those numbers. The historical /24 gives a notional internet edge of 256 IPv4 addresses, but address count says little about capacity. A /24 can support a small set of critical services, a management edge, a NAT pool, a protected application, a test environment or a larger design hidden behind load balancers. It can be essential or idle. Without live DNS, service names, route traffic and operational documents, it cannot be converted into rack count or workload scale.

The current absence of public route announcements pushes the analysis further away from installed capacity. If the /24 is dormant, then the live service may run elsewhere. If the route is standby-only, it may not be carrying production traffic. If the route was retired, its historical capacity is no longer relevant. All three options are plausible from public data, and each requires different verification.

The financial-sector context raises the bar because partial recovery can be worse than a clean failover. A secondary site might restore internal access but not client trading. It might restore client portals but not market connectivity. It might restore applications but with stale data. It might accept traffic but have limited public evidence bandwidth for opening-hour demand. It might support one business line but not another.

The useful question is therefore not "does a data centre exist?" It is "which named functions can operate at the recovery site, at what load, after which failure, and with what data loss?" Public evidence has not answered that question for AS150124.

The affected parties are broader than one rack

If a Maybank Securities Thailand continuity site fails, the immediate owner of the incident may be a technology team, but the affected parties can include clients, brokers, operations staff, compliance teams, market counterparties, call-centre staff, settlement functions and regulators. Even a narrow network outage can spread through business processes because securities operations run on time windows.

Client-facing systems are the obvious layer. Investors may need account access, trade status, portfolio information, funding status or order channels. If a primary site fails and the backup site does not take over cleanly, clients may see latency, unavailable functions or inconsistent information. The reputational cost can outlast the technical fault.

Market-facing systems are less visible but more time-sensitive. Trading infrastructure depends on exchange connectivity, market data, order validation, risk controls and audit logging. If recovery restores a portal but not the market path, the visible application may appear alive while the business process is impaired. If market connectivity is restored but back-office reconciliation is delayed, risk moves into settlement and reporting.

Internal operations also matter. Staff need emergency access, identity systems, communication channels and runbooks that remain available when the primary office or network is impaired. A co-location site can host technical systems while staff connectivity still depends on home broadband, mobile networks, VPN concentrators or office access. Failure of any one layer can slow recovery.

Data integrity is the deepest risk. A recovery site can be technically reachable and still carry stale, incomplete or unverified data. Securities data needs auditability. Recovery should prove not only that systems restart but that orders, confirmations, account balances, logs and regulatory records are complete and reconciled. A backup that cannot be trusted quickly may force manual controls that reduce service capacity.

The public AS150124 record cannot reveal which of these populations depends on the site. The reason to watch it is that a Maybank-labelled data-centre edge sits in the kind of environment where small infrastructure dependencies can have larger market consequences.

Disaster recovery has to be exercised, not assumed

The public Maybank reporting around business continuity and disaster recovery is constructive because it shows that the company knows the topic exists. The next question is the quality of exercise. A disaster-recovery plan is not proven by its presence in a report. It is proven by a dated test that moves real services, people and data through the recovery path.

For a site associated with AS150124, the minimum exercise would include network activation. If the 110.49.10.0/24 route is meant to be part of recovery, the test should announce it, validate routing, confirm inbound and outbound reachability, measure convergence, and ensure route filters accept it. If the site no longer uses the ASN, the test should state what replaced it.

The exercise should also include power and cooling. Recovery load should run long enough to show that UPS, generator, cooling and environmental controls can support the work. It should include a scenario in which the primary site is unavailable, not just a planned maintenance drill with both sites healthy. It should record exceptions and corrective actions.

Application recovery is separate. Databases should be restored or failed over with a measured recovery point and recovery time. Client access, staff access, market access, monitoring, logging and communication should be validated. A test that restarts servers but leaves users unable to transact does not establish business recovery.

People and authority should be part of the test. Who declares the event? Who contacts AIS/AWN? Who authorises the route change? Who verifies data integrity? Who communicates to management, regulators or clients? Who has after-hours access to the facility? A good data-centre design can be slowed by approval ambiguity.

None of these details need to be fully public. But without at least a public statement of test cadence, scope and outcome, external confidence remains limited. The APNIC record and Maybank continuity disclosures justify asking for a test report. They do not replace it.

Power growth and permitting shape the recovery market

Thailand has become a more active data-centre market as cloud, telecom and enterprise demand grows. The Board of Investment has promoted cloud and data-centre investment, and official investment material increasingly treats digital infrastructure as a strategic sector. That broader market context affects even specialised enterprise and financial sites.

The constraint is not only whether a facility exists. It is whether power, cooling, land, permits, contractors and network capacity are available when a site needs to expand or repair. A recovery site may be perfectly adequate for a past workload and constrained for a current one. More compute, stronger security inspection, higher data volumes and tighter logging can all increase load. If the recovery footprint was designed in 2022, its 2026 adequacy should be retested.

Permitting and maintenance also affect resilience. Generator replacement, fuel-system changes, fire-system upgrades, electrical works and cooling expansion can require approvals, supplier lead times and planned downtime. A site can remain available in normal operation while running with reduced redundancy during construction or maintenance. Customers need visibility into those windows because they may overlap with business-critical periods.

The Maybank-labelled public record has no capacity expansion data. It does not say whether the site has reserved power, whether additional cabinets are planned, whether upgrades occurred after the 2024 route disappearance, or whether the ASN was retired because the network design changed. In a fast-growing data-centre market, silence should not be read as stability.

The right question for a financial customer is not whether Thailand has data-centre investment momentum. It is whether this particular recovery arrangement has current, reserved, tested and contractually protected capacity for the workloads assigned to it.

What would raise confidence

MAYBANK Data Center Co-Location could become a much stronger public infrastructure profile without exposing sensitive architecture. The first improvement would be a current operating statement. It should say whether AS150124 is retired, dormant for standby recovery, or replaced by another network design. If the ASN is still part of continuity, the statement should identify the intended role of 110.49.10.0/24.

The second improvement would be a responsibility matrix. It should distinguish Maybank Securities Thailand, Advanced Wireless Network, any AIS data-centre operator, facility staff, carriers, remote-hands providers and application vendors. It should identify who owns power, cooling, physical access, BGP activation, route authorization, cross-connects, security appliances, backup storage, disaster declaration and client communication.

The third improvement would be current route evidence. A public looking-glass result, a controlled re-announcement, a monitoring report or an audit statement could show that the backup route can be activated and propagated. If the current design intentionally avoids public BGP, a high-level explanation would prevent readers from misreading AS150124's silence as pure neglect.

The fourth improvement would be facility resilience evidence. Maybank or the relevant operator could disclose test cadence for utility-loss, generator, UPS, cooling, fire and carrier failover scenarios. It need not reveal rack diagrams. It should identify what function was tested, when, with what result, and what exceptions remain open.

The fifth improvement would be service-specific recovery evidence. Securities operations need more than powered servers. A useful report would state recovery time and recovery point objectives by function, show that market access and client access are included, and confirm data reconciliation after failover.

The sixth improvement would be routing-security stewardship. The valid ROA is a positive signal; it should be paired with a current route-management policy, contact validation, route-filtering process and documented activation authority. A dormant but well-governed route is different from an abandoned artefact.

Those disclosures are proportionate. They would let external readers distinguish between a decommissioned historical route, a standby recovery design and a live but private data-centre architecture.

What not to infer

Do not infer current live service from the ASN registration. APNIC status means the entity exists and is active in registry terms. It does not mean the route is announced or that customers can reach services through it.

Do not infer Maybank ownership of the whole facility from the Maybank-labelled ASN. The technical and abuse contacts point to AWN, the address points toward an AIS data-centre context, and co-location normally divides responsibilities among several parties.

Do not infer facility-grade resilience from the word "data centre." The public record does not disclose A/B power, generator runtime, cooling redundancy, fire design, flood exposure, maintenance history or remote-hands commitments for the Maybank deployment.

Do not infer carrier diversity from the broader Pathum Thani ecosystem. Facility listings and exchange factsheets show useful interconnection context, but AS150124 has no current public neighbours and the historical route showed one upstream-side neighbour in the RIPEstat snapshot reviewed here.

Do not infer that Maybank's business-continuity disclosures prove this specific ASN. The annual report supports the importance of recovery arrangements. It does not name AS150124 or publish the site architecture behind the Maybank-labelled co-location record.

Finally, do not infer failure from absence. The ASN may be dormant by design, or services may have migrated to private/provider networks. The correct conclusion is not that the system is broken. It is that public evidence is limited public evidence to prove current recoverable capacity.

What to watch next

The most important signal would be a new route announcement from AS150124. If 110.49.10.0/24 reappears, analysts should check whether it is visible through multiple collectors, whether the ROA remains valid, which neighbours appear, and whether the route persists or only appears during a short test. A new prefix would require the same checks plus registry and authorization review.

The second signal would be a change in APNIC records. Updated contacts, a new sponsor, a new address, a changed description or a removed Maybank label would show that the operating arrangement has changed. Contact validation and route-maintainer updates would improve confidence in stewardship.

The third signal would be Maybank disclosure. A future One Report or governance document could say more about disaster-recovery testing, separated data-centre operation, cyber-resilience controls or technology risk. Even a short statement that the company tested recovery at a separate data-centre site would help, if it identified scope and timing.

The fourth signal would be AIS/AWN facility disclosure. New data-centre pages, certification claims, interconnection updates, generator or sustainability statements and TH-IX facility changes could improve the context around the Pathum Thani address. Those updates would still need customer-specific interpretation.

The fifth signal would be market stress. Large cloud and data-centre investment in Thailand can tighten power, permitting and construction resources. If regional capacity becomes constrained, financial-sector recovery sites need stronger evidence of reserved power, maintenance priority and expansion rights.

The final signal is silence. If AS150124 remains unannounced and the public records do not change, the evidence grade should stay weak. Silence may be operationally benign, but it cannot support a claim of current internet-facing capacity.

A narrow conclusion is the honest one

MAYBANK Data Center Co-Location is a real public registry signal with a specific Thailand footprint. APNIC records name the Maybank-labelled co-location entity, tie it to AS150124, show AWN technical administration and identify a Pathum Thani data-centre-style address. RIPEstat history shows that the ASN originated 110.49.10.0/24 for almost two years. The route still has a valid origin authorization.

The same public evidence forces a downgrade. AS150124 is not currently announced in the 12 July 2026 RIPEstat view. It has no current public prefixes, no current observed neighbours and no IPv6 origin. The public record does not prove which Maybank systems, if any, still use the site. It does not prove physical power diversity, generator endurance, cooling capacity, carrier separation, facility maintenance, recovery timing, data integrity or customer impact.

For a securities company, those unanswered questions matter. A backup site can be the difference between a controlled incident and an operational interruption. But a named co-location record is only the starting point. The real test is whether the site can carry defined functions, at defined load, after a defined failure, with current data and accountable support.

Until that evidence is visible, MAYBANK Data Center Co-Location should be monitored as a weakly evidenced but high-relevance infrastructure dependency: credible enough to ask hard questions, not strong enough to certify resilient capacity.