Summary

  • The Svea abuse surface in the RIPE registry is registered-valid: the routing object names Svea Bank AB and an abuse-c role, and RIPE policy requires an annually validated abuse mailbox.
  • It is operationally unproven: no public source shows the mailbox is monitored, and the registry's own remedy addresses incorrect contact data rather than an operator that ignores reports.
  • The filing test has three public steps — maintainer contact, the RIPE NCC reporting procedure, the Arbiters Panel — each producing an outcome a reporter can observe and date.

On 17 December 2025 Sweden's financial supervisor, Finansinspektionen, announced a remark and an administrative fine of SEK 170 million against Svea Bank AB for violations of central anti-money-laundering provisions, citing deficiencies in general and customer risk assessments and in customer due diligence (Finansinspektionen's sanction notice). The underlying Swedish decision, FI dnr 23-13249, records the fact that anchors this briefing: Svea Ekonomi AB merged into Svea Bank AB on 3 January 2022 and all business previously run by Svea Ekonomi AB continued under the bank (the decision document). Neither document mentions the RIPE Database, internet number resources or abuse contacts. The supervisor's relevance here is narrower: it demonstrates that an outside body tested Svea's own claims about its remediation and did not accept them at face value.

The registry surface has not followed that merger. Third-party renders of the RIPE Database entry for AS211899 show the autonomous system registered to organisation ORG-SBA155-RIPE, org-name Svea Bank AB, registration number 556158-7634, with abuse-c SEAR1-RIPE — while person object JE4899-RIPE, attached to the same infrastructure, still carries the address "Svea Ekonomi AB" (IPIP.NET render of AS211899). The mirrors also disagree with one another. One render gives the abuse contact as a named personal mailbox on the operator's own mail domain, and dates the organisation object's last modification to 1 December 2022 (Sitezilla render); another shows the same personal-address rendering with a last-modified value of 13 May 2026 (IPGeolocation.io render). A third surface sits on the provider-independent block 193.105.138.0/24, netname SVEA-EKONOMI-SE, where the rendered abuse contact resolves to a mailbox belonging to another network operator (IPIP.NET record for the block).

Registered validity is not in dispute, and that is precisely why it cannot be read as proof of operation. RIPE policy requires a mandatory abuse-c attribute in organisation objects, a single abuse-mailbox attribute in the referenced role object, and unrestricted visibility of that mailbox through whois and the registry's APIs (RIPE NCC's abuse-c information, ripe-705). The same policy requires the RIPE NCC to validate the abuse-mailbox at least annually — but validation is technical: syntax, domain and mail-server configuration, to determine whether the address is correctly configured to receive messages (policy proposal 2017-02). Nothing in that test establishes that anyone reads what arrives.

The RIPE NCC states the boundary itself: its role is to ensure abuse contacts are valid and up to date, handling a report is the network operator's responsibility, and there is nothing the registry can do if an operator chooses not to reply (RIPE NCC abuse support page). Its reporting procedure covers incorrect contact information after a reporter has first tried the maintainer, and routes disputes to the Arbiters Panel; reports of spam, phishing and other network abuse originating outside the RIPE NCC's own network do not fall within its registry responsibilities (RIPE NCC reporting procedure).

That produces a concrete filing test.

First, contact the maintainer responsible for the object and keep the dated record. This is the step the registry's procedure expects a reporter to have taken before escalating.

Second, if the contact data is wrong — a role object that names a dissolved company, a mailbox that bounces or that belongs to a third party — escalate to the RIPE NCC under its reporting procedure. The observable outcome is not a reply from Svea; it is a registry action: the report is forwarded and tracked, and if the mailbox is incorrect the responsible party is followed up. A corrected role object or an updated abuse-mailbox is evidence that this step worked.

Third, if the data remains wrong or the dispute is about registry process rather than facts, the Arbiters Panel is the documented destination.

What would count as repair on the Svea surface is therefore specific. The registry's own guidance is explicit that changing an abuse contact means editing the role object that holds the abuse-mailbox — not renaming the organisation (abuse-c FAQ, RIPE Database abuse-contact documentation). A durable repair would show a role object with a monitored, identified mailbox, a person object no longer carrying the name of a company that ceased to exist on 3 January 2022, and an end to the mirror-level contradiction about which address is operative.

Three earlier BTW reports established the split surface, the remedy mechanism the policy already defines, and the durability standard: the first documented the registry-versus-accountability gap, the second set out what RIPE policy would require as repair, and the third placed the case inside RIR Watchdog coverage. None of them located evidence that a report filed against the Svea surface produced any response, and none found a post-sanction registry correction. This briefing adds the part a reader can act on: the path to file, the body that receives the escalation, and the artefacts that would show the path ended somewhere. The related directory entry is the Svea Eknonomi Abuse Role.

Uncertainty runs in one direction here. The WHOIS renders are third-party mirrors, not the authoritative registry query, and they contradict one another on timestamps; the Finansinspektionen decision is silent on registries and is used only as a standard of proof, not as a finding about abuse contacts. The absence of evidence that the mailbox is monitored is not evidence that it is not, and a validated address and a staffed address are simply different facts.