RFC 3615

RFC 3615: A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging 🦋

Title block, the tea: This one is from the Network Working Group, written by J. Gustin and A. Goyens of SWIFT, dated September 2003. It's Category: Informational 💅, so it's giving "here's some info," not "you must do this." The original doesn't list any RFCs that it obsoletes or updates, so no drama there 🙈

---

Status of This Memo 📝

This memo provides information for the Internet community. It does not specify an Internet standard of any kind, so nobody's getting graded on it 😭 Distribution of this memo is unlimited, so share it with everyone you know 🌸

Copyright Notice ©️

Copyright (C) The Internet Society (2003). All Rights Reserved. Mine, theirs, and everybody's 🎀

Abstract ✨

This document describes a Uniform Resource Name (URN) namespace that is managed by SWIFT for usage within messages standardized by SWIFT. Basically, it's the naming system for the stuff inside SWIFT messages 💖

1. Introduction ✨

Okay so SWIFT is an industry-owned cooperative. It's giving "the banks all chipped in." 🏦 It supplies secure, standardised messaging services and interface software to over 7,500 financial institutions in 199 countries. The SWIFT community includes banks, broker/dealers and investment managers, as well as their market infrastructures in payments, securities, treasury and trade. Iconic guest list, honestly 👑

The whole point of this namespace is to keep the names of things used in messages between financial institutions stable and unique. SWIFT is one of the main standardization bodies for financial messages and services. That standardization process decides the structure and meaning of messages for the various financial services those institutions offer. The names of items, like the XML schema that describes the message itself, have to still identify the resource even years after the message was exchanged. Long-term memory energy 🧚

Here's the lowkey important bit: the same resource can live in multiple physical locations, so it can have multiple URLs, but it only ever gets a single URN 🔥

2. Specification Template 📋

Namespace ID:

The namespace ID is "swift". Main character name, no notes 💅

Registration Information:

Version 1, Date: 2001-08-01

Declared registrant of the namespace:

SWIFT s.c.r.l.
Avenue Adele 1
B-1310 La Hulpe
Belgium

Declaration of syntactic structures:

Okay, this part is kind of a plot twist 😭 The Namespace Specific String is a flat space of <URN chars> [1], which has no knowable structure outside the SWIFT community's internal resolver. Future changes to the assignment methods might let others assign sub-spaces of the flat namespace. But again, that knowledge is only valid internally and should never be inferred or relied upon externally. Look but don't touch, bestie 🙈

Relevant ancillary Documentation:

None. Literally nothing extra, so we're good 🌈

Identifier uniqueness considerations:

Identifiers are assigned by SWIFT URN Registration, which guarantees uniqueness. The trick is keeping track of already assigned names and comparing every new proposed name against the ones in the database. If the name already exists, a new one has to be proposed. No duplicates allowed, the girls don't share the same name 💖

Identifiers persistence considerations:

The assignment process guarantees that names are not reassigned. On top of that, SWIFT URNs are guaranteed to remain valid for 15 years. That's a whole decade and a half of being iconic 🍓

Process of identifiers assignment:

Names are granted via SWIFT proprietary registration procedures. So it's SWIFT's own process, not a public one 🔒

Process for identifier resolution:

SWIFT URNs are resolved via URN resolvers run under SWIFT responsibility. SWIFT owns the resolving, so that's on them 💅

Rules for lexical equivalence:

No special consideration. Easy, no drama ✨

Conformance with URN syntax:

No special consideration. Also easy 🫶

Validation mechanism:

None specified. The original just doesn't say anything here, so neither will I 🙃

Scope:

This namespace is reserved for the global financial community. Exclusive VIP section, very on brand 👑

3. Examples 🧚

The following examples are not guaranteed to be real. They are listed for pedagogical reasons only, so they're practice names, not official ones 🌸

urn:swift:xsd:epp$mi.i-2.0
urn:swift:type:fin$103

4. Security Considerations 🔐

Since the URNs in this namespace are opaque, there are no additional security considerations beyond the ones that normally come with using and resolving URNs in general. Nothing extra scary, just the usual stuff 💜

It is noted however that attempting to resolve a SWIFT URN through a resolver other than the one provided by SWIFT is error prone. In any case, it is not considered authoritative. Basically, don't go shopping for a random resolver and trust whatever it tells you, that's how you get burned 😭💀

5. IANA Considerations 🌈

IANA has registered formal URN namespace 15, to SWIFT, within the IANA registry of URN NIDs. Official paperwork, very neat 🎀

6. Normative References 📚

• [1] Moats, R., "URN Syntax", RFC 2141, May 1997.
• [2] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "Uniform Resource Name (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.

7. Authors' Addresses 💌

Jean-Marc Gustin
SWIFT s.c.r.l.
Avenue Adele, 1
B1310 La Hulpe
Belgium

EMail: jean-marc.gustin@swift.com

Andre Goyens
SWIFT s.c.r.l.
Avenue Adele, 1
B1310 La Hulpe
Belgium

EMail: andre.goyens@swift.com
URI:   http://www.swift.com

8. Full Copyright Statement ⚖️

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to others. Derivative works that comment on or otherwise explain it, or help with its implementation, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, as long as the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The one exception is when needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed. Translating it into languages other than English is also allowed 🌍

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. Forever is a long time, and they mean it 💖

This document and the information contained herein is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Read that one carefully, it's the legal fine print 🙈

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. Thanks to them for keeping the lights on ✨