Welcome to whitepaper Discussions!

[pv-sarvesh]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[msantore]

Hello,

I'm Michael Santore, founder and CEO of BlockSkunk. We build the multi-party system of record for regulated industries: one shared, cryptographically verifiable record alongside everyone's systems, so counterparties stop reconciling five versions of ownership, settlement, and rules. Our risk register embeds compliance controls into a permissioned ledger.

I joined via the LFDT session on institutional tokenization. We see the same failure mode OTAS names: fragmented formats, trapped collateral, and duplicated compliance. Standards belong at the seams (identity, compliance, metadata, settlement), not inside any one stack.

Today we focus on SEC/FINRA RIA workflows, with ISO 27001, EU AI Act, and SOC 2 Type 2 evidence paths designed for cryptographic attestation. Next up: GENIUS and MiCA compliance and Real Estate workflows, with a strong emphasis on enterprise data governance.

Looking forward to contributing on the discussions and supporting the community.

-- Michael

[pv-sarvesh]

Welcome, Michael — really glad you found us through the LFDT institutional tokenization session, and thanks for the thoughtful introduction.

You've put your finger on exactly the thesis OTAS is built around: the standard belongs at the seams — identity, compliance, metadata, settlement — not inside any one stack. That's the whole bet, so it's great to have someone thinking the same way join the conversation.

Given where your work sits (SEC/FINRA, ISO 27001, SOC 2, and the MiCA/GENIUS paths you're building toward), a few of our open questions look right in your wheelhouse — I'd love your take on any of them:

• Compliance reason-code taxonomy — can we agree on a stable, machine-readable set of compliance reason codes that map cleanly onto FATF / MiCA / BSA-AML? Your regulated-workflow experience would be especially valuable here.
• Metadata canonicalization — how far the core descriptor should align with ISO 20022 / FIX / FpML, which connects to your data-governance focus.
• Referencing incumbents — how OTAS should reference rather than replace existing rails, i.e. your "seams, not inside any one stack" point made concrete.

They're all in the Discussions tab under Q&A. Jump into whichever resonates — even a challenge to an assumption or a pointer to prior art is genuinely useful. Looking forward to your input.

We'd also love to have you at our monthly OTAS community call — it's an open forum, and hearing your perspective on the compliance and metadata layers live would be a great addition. I'll make sure you have the details. Looking forward to having you in the mix.

[msantore]

Thanks @pv-sarvesh - Will aim to join the next monthly call and follow the Q&A threads.

One adjacent idea: NIST OSCAL may be worth exploring at the security-control evidence seam. Not for FATF/MICA/BSA codes, or 20022/FIX/FpML, but as a clean way to attach control findings to an OTAS workflow without pulling the standard inside a control stack.

https://github.com/usnistgov/oscal

[MukulKolpe]

Thanks so much, @msantore, and delighted you'll be joining the next community call.

OSCAL is an excellent pointer, and the way you've scoped it is exactly right: not the AML/CFT codes, not the instrument semantics, but the security-control evidence seam. That's genuinely where the draft is thinnest, so this is a helpful nudge. Today it's a SOC 2 PDF exchanged during onboarding diligence.

The attach-by-reference framing is the part that appeals, keeping the evidence itself outside the standard and referencing it, rather than pulling control logic in.

One thing we'd value your view on: control evidence attaches to an operator or venue, not a party to a transfer, so it may sit somewhere other than the identity layer. The expiry semantics differ too: an assessment covers a window that has closed, where an eligibility credential is valid or revoked at the moment of the check.

Thanks again for engaging so substantively straight away. Looking forward to having you on the call.

[307sagar]

Hi,

I am Amit, working with a Central Bank on wholesale payments.
I have to say a very comprehensive start !

Couple of points that might add more clarity on some of the layers that you have got in there.

• Settlement networks : settlement layer should guarantees the
  1.Technical Finality, and - this is mostly covered under atomic settlement

2. Legal Finality - needs more generalised approach on standards on compliance, specifications/rule books for a legal construct to define settlement.
   Different jurisdictions has different definition of them : how to guarantee settlement finality - is it point of irrevocability or point of final settlement. Food for thought - https://www.bis.org/cpmi/publ/d101a.pdf
   Principle 8: Settlement finality
   An FMI should provide clear and certain final settlement, at a minimum by the end of the value date. Where necessary or preferable, an FMI should provide final settlement intraday or in real time.
   Some of the considerations -
3. FMI’s rules and procedures should clearly define the point at which settlement is final.
4. An FMI should clearly define the point after which unsettled payments, transfer instructions, or other obligations may not be revoked by a participant.

Suggestion on 'Standard should/shouldn't do' : SettlementProposed (Technical SF && Legal SF constructs) -> Committed| Settled | Aborted - there can be a scope to use both technical finality and legal finality inputs as parameters to have a safe method.
□ Settlement coordinator - after receiving both the party's atomic legs states - it should be in committed state. That gives the guarantee that the transaction is enqueued and will not be lost.[thinking from a payment processing angle]

□ For Interoperability - I have seen mentioning of various forms of solutions, and not cryptographic proofs/light clients to interoperate. Would it be worth exploring generic standard for message constructs that can be helpful for improving hetero systems communications ?

Happy to speak on the next community call.

Thanks !

[MukulKolpe]

Thanks @307sagar, this is a valuable addition, and great to have you here.

You've named the gap precisely. Section 6.1 treats atomic settlement as the whole finality story, but that's only technical finality. Legal finality is separate and jurisdiction-dependent, and as you say, the point of irrevocability and the point of final settlement aren't always the same moment. PFMI Principle 8 is the right anchor, and distinguishing "when may an instruction no longer be revoked" from "when is settlement final" is a distinction the current text collapses. It belongs in the settlement layer explicitly. The PFMI link looks like a good read on exactly this; appreciate you sharing it.

Your state-model suggestion is a real improvement. The draft's lifecycle is SettlementProposed -> Settled | Aborted, which has nowhere to express the guarantee you describe. A Committed state seems like a good proposal; once the coordinator holds both legs' states, the transaction is enqueued and won't be lost, even before final settlement. It also gives legal finality somewhere to attach, since the revocability boundary can sit at the transition into Committed. Treating technical and legal finality as distinct inputs to the transition, rather than assuming atomicity implies both, is the right shape.

On interoperability, the draft lists bridging mechanisms (HTLC, escrow/notary, shared-ledger) but says little about the message layer beneath them, how two heterogeneous systems express and verify a settlement instruction's state in the first place. That common message construct feels like the more tractable thing to standardize; the underlying verification approach, cryptographic proofs among them, is less settled, with finality models and proof formats varying enough across ledgers that it's probably too early to standardize on one. Worth separating the two.

Would be great to have you on the next call to work through the finality distinction. Thanks again.