Frontend->Backend: message `

[!WARNING] This is currently a WIP 🚧 Under Construction 🚧 Unsure about the "No peer dependencies" requirementAt a minimum DX cannot include determining version compatibility Add package dependencies Can we make jws_signer work?

Example { "vc": { "credentialSubject": {}, "evidence": [{ "region": "US" "diligence": [{ "kind": "document_verification", "checks": ["drivers_licx`ense", "utility_bill"], }, {

{ "metadata": { "from": "did:jwk:eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5IiwieCI6Im9rdHVoYnVrRDZrVW13N0ZvZjFuVG5UY0d6OGg4SlFkeTE0VGVqZWJ3Tk0ifQ", "kind": "offering", "id": "offering_01htznvjxbfwprrmtv58q9cb2w", "createdAt": "2024-04-08T20:19:39Z", "updatedAt": "2024-04-08T20:19:39Z", "protocol": "1.0" }, "data": {

What's the benefit of mutating the pending_at, settled_at, voided_at columns vs appending new rows? How are fees going to be represented and linked to the money movement they're associated with? How do money movements get associated with exchanges? What does the account model look like? In the example, Wire funds from TBD operations account to Circle inserts a single ledger entry - where do we track that those funds were expected to go to our circle balance?

Overview The ledger module contains our source of truth for all balances (customer stored balances as well as TBD internal treasury balances) and money movements impacting the balances. The core ledger is simply an append only table with debits and credits against balances. Requirements: Strong consistency Multi currency Append only entries Use cases:

Summary <!-- omit in toc --> This design doc covers all of the modules, verbs, and data models needed to facilitate a USD -> MXN remittance via the tbdex protocol. A core functionality of our PFI is moving money. For our PFI, considerations around money movements can be divided into two broad areas: The externally accessible tbdex API Payment rails which facilitate funds movements Supporting infrastructure to satisfy requirements from accounting, treasury, and audit An overarching principle is to optimize our design for satisfying our short term requirements while remaining extensible enough to iterate on in the future.

Statement of Work Terse explanation / summary / overview of what we'll be focusing on this year KCC issuance e2eOnboarding to TBD PFI via DIDPay Onboarding to YC PFI via DIDPay Showcasing CA Remittances Showcasing PFI Interoperability

const rfq = { payin: { amount: "100.00", paymentDetailsHash: }, payout: {}, claims: [], signature: "" }

Slack Channel - #pfi Status – WIP Author – plew A core functionality of our PFI is moving money. Initially, we will support transacting with USD, USDC, and MXN. For a financial institution, considerations around money movements can be divided into two broad areas: Payment rails which facilitate the movement itself Supporting infrastructure to satisfy requirements from accounting, treasury, and audit This doc outlines the main components required to launch our production PFI in Q4.

@plew , @moejangda protocol versioning We propose using major and minor versions only (no patch) for the protocol itself and adding protocol as a required field to resourceMetadata and messageMetadata, respectively (TS types used as an example): export type ResourceMetadata<T extends ResourceKind> = { /** The author's DID */ from: string /** the resource kind (e.g. Offering) */ kind: T

sequenceDiagram autonumber participant W as Wallet participant P as PFI W->>P: Give me OIDC Metadata P->>W: OIDC Metadata W->>P: Get SIOPv2AuthRequest

sequenceDiagram autonumber participant D as DIDPay participant P as PFI D->>P: RFQv1.1 P->>D: Quotev1.1 P->>P: Redeploys with updated version of tbdex SDK now on v1.4 D->>P: Orderv1.1

sequenceDiagram autonumber actor u as Randy McRando participant idv participant credentials participant oidcauth u->>idv: HandleSIOPV2AuthRequest activate idv

Initiating IDV Flow sequenceDiagram autonumber participant W as Webview participant D as DIDPay participant P as PFI D->>D: Resolve PFI DID. Find IDV service D->>P: GET did:ex:pfi?service=IDV

@startuml header Pre-authorized Code Flow title Pre-authorized Code Flow Pre-authorized Code Flow between a holder and an issuer end title autonumber

Direct Issuance sequenceDiagram autonumber participant D as DIDPay participant W as Widget participant I as Issuance Server D->>D: Generate DID. Store private key securely D->>I: Get Challenge

sequenceDiagram autonumber

// CURRENT const quote = { payin: { currency: '', amount: '', fee: 'OPTIONAL', }, payout: { currency: '', amount: '',