liquidity account (reserve funds pending) - ASE->>ASE: Credits the recipient's account by the payment amount - ASE->>Rafiki: Resolve funds (post) + Rafiki->>FSP: Fires webhook event when incoming payment completes + FSP->>Rafiki: Withdraws payment amount from incoming payment
liquidity account (reserve funds pending) + FSP->>FSP: Credits the recipient's account by the payment amount + FSP->>Rafiki: Resolve funds (post) Rafiki->>Rafiki: Two-phase transfer complete `} /> diff --git a/packages/documentation/src/content/docs/es/overview/concepts/clearing-settlement.mdx b/packages/documentation/src/content/docs/es/overview/concepts/clearing-settlement.mdx index 72958dedeb..7c3458fa11 100644 --- a/packages/documentation/src/content/docs/es/overview/concepts/clearing-settlement.mdx +++ b/packages/documentation/src/content/docs/es/overview/concepts/clearing-settlement.mdx @@ -6,25 +6,25 @@ import { LinkOut } from '@interledger/docs-design-system' ## Compensación -Cuando se realiza un pago a través de los canales bancarios tradicionales, el dinero no se transfiere de forma instantánea. Primero, se realizan verificaciones para confirmar que el dinero existe y se puede transferir. Las redes de compensación son responsables del intercambio de mensajes entre las ASE para facilitar estas verificaciones. Este proceso se denomina compensación. Cuando un pago se compensa correctamente, significa que la ASE del pagador tiene una obligación con la ASE del beneficiario. +Cuando se realiza un pago a través de los canales bancarios tradicionales, el dinero no se transfiere de forma instantánea. Primero, se realizan verificaciones para confirmar que el dinero existe y se puede transferir. Las redes de compensación son responsables del intercambio de mensajes entre las FSP (financial service provider) para facilitar estas verificaciones. Este proceso se denomina compensación. Cuando un pago se compensa correctamente, significa que la FSP del pagador tiene una obligación con la FSP del beneficiario. El [Interledger Protocol (ILP)](/es/overview/concepts/interledger) no es una red de compensación tradicional, pero funciona de manera similar. -- Las ASE que implementan el protocolo deben convertirse en [pares](/integration/requirements/peers) para realizar transacciones entre sí. Esto es comparable a la banca tradicional, donde las ASE deben utilizar la misma red de compensación. Una ASE no puede usar Interledger para realizar transacciones con otra ASE a menos que ambas hayan implementado el protocolo y se hayan interconectado. -- Las ASE interconectadas intercambian paquetes ILP, que son paquetes de valor que contienen información de las transacciones. Los paquetes ILP son similares a los mensajes intercambiados durante el proceso de compensación tradicional. +- Las FSP que implementan el protocolo deben convertirse en [pares](/integration/requirements/peers) para realizar transacciones entre sí. Esto es comparable a la banca tradicional, donde las FSP deben utilizar la misma red de compensación. Una FSP no puede usar Interledger para realizar transacciones con otra FSP a menos que ambas hayan implementado el protocolo y se hayan interconectado. +- Las FSP interconectadas intercambian paquetes ILP, que son paquetes de valor que contienen información de las transacciones. Los paquetes ILP son similares a los mensajes intercambiados durante el proceso de compensación tradicional. - El intercambio exitoso de paquetes ILP entre pares crea obligaciones entre ellos que deben liquidarse. La recepción de un paquete ILP cumplido es básicamente un pagaré condicional —una promesa de pago— que afecta los saldos contables financieros entre los pares. Puede obtener más información sobre la compensación en relación con ILP en los
### AML (Prevención del lavado de dinero)
-Las ASE cumplen con las leyes y regulaciones contra el lavado de dinero para detectar y prevenir el lavado de dinero y otras actividades financieras sospechosas.
+Las FSP cumplen con las leyes y regulaciones contra el lavado de dinero para detectar y prevenir el lavado de dinero y otras actividades financieras sospechosas.
### KYC/KYB (Conozca a su cliente/negocio)
-Las prácticas de KYC y KYB garantizan que las ASE verifiquen la identidad de sus clientes mediante la recopilación de documentos de identidad y comprobantes de domicilio, la verificación de registros comerciales, la consulta de listas de sanciones y otros procesos.
+Las prácticas de KYC y KYB garantizan que las FSP verifiquen la identidad de sus clientes mediante la recopilación de documentos de identidad y comprobantes de domicilio, la verificación de registros comerciales, la consulta de listas de sanciones y otros procesos.
### Gestión de cuentas de los usuarios
-Las ASE gestionan la creación, el mantenimiento y la seguridad de las cuentas de sus clientes y de los saldos de dichas cuentas. Del mismo modo, son responsables de autenticar a sus clientes y de ofrecerles canales seguros para que interactúen con sus cuentas a través de aplicaciones móviles, sitios web u otras interfaces.
+Las FSP gestionan la creación, el mantenimiento y la seguridad de las cuentas de sus clientes y de los saldos de dichas cuentas. Del mismo modo, son responsables de autenticar a sus clientes y de ofrecerles canales seguros para que interactúen con sus cuentas a través de aplicaciones móviles, sitios web u otras interfaces.
### Libro contable
-Dado que las ASE gestionan depósitos y retiros a través de métodos de pago externos (como transferencias bancarias, tarjetas de crédito y otros servicios), deben registrar en su libro contable todas las transacciones y la información de saldos.
+Dado que las FSP gestionan depósitos y retiros a través de métodos de pago externos (como transferencias bancarias, tarjetas de crédito y otros servicios), deben registrar en su libro contable todas las transacciones y la información de saldos.
diff --git a/packages/documentation/src/content/docs/es/overview/concepts/multi-tenancy.mdx b/packages/documentation/src/content/docs/es/overview/concepts/multi-tenancy.mdx
index d863b79d68..41fad0d5b5 100644
--- a/packages/documentation/src/content/docs/es/overview/concepts/multi-tenancy.mdx
+++ b/packages/documentation/src/content/docs/es/overview/concepts/multi-tenancy.mdx
@@ -2,9 +2,9 @@
title: Multitenencia
---
-La multitenencia es un enfoque arquitectónico que permite que una sola instancia de Rafiki preste servicio a múltiples entidades que administran cuentas (account servicing entities, ASE). Esto permite a las organizaciones compartir servicios de aplicaciones y recursos de bases de datos, al tiempo que mantienen el aislamiento y la seguridad de los datos. Al implementar la multitenencia, Rafiki simplifica el proceso de integración para las ASE, lo que hace que la incorporación sea más rápida y sencilla.
+La multitenencia es un enfoque arquitectónico que permite que una sola instancia de Rafiki preste servicio a múltiples entidades que administran cuentas (financial service providers, FSPs). Esto permite a las organizaciones compartir servicios de aplicaciones y recursos de bases de datos, al tiempo que mantienen el aislamiento y la seguridad de los datos. Al implementar la multitenencia, Rafiki simplifica el proceso de integración para las FSP, lo que hace que la incorporación sea más rápida y sencilla.
-En un entorno multicliente, la entidad responsable de administrar una instancia de Rafiki que presta servicio a múltiples ASE se denomina **operador**. Cada ASE que utiliza la instancia compartida de Rafiki se denomina **cliente**.
+En un entorno multicliente, la entidad responsable de administrar una instancia de Rafiki que presta servicio a múltiples FSP se denomina **operador**. Cada FSP que utiliza la instancia compartida de Rafiki se denomina **cliente**.
## Funciones y responsabilidades del operador y del cliente
@@ -28,7 +28,7 @@ Los clientes se agregan a través de la API de administración del backend o de
### Cliente
-Un cliente es una ASE que se conecta a una instancia compartida de Rafiki en lugar de ejecutar su propio entorno. Para conectarse al entorno compartido, cada cliente debe instalar y ejecutar su propio servicio de integración. Los clientes son responsables de lo siguiente:
+Un cliente es una FSP que se conecta a una instancia compartida de Rafiki en lugar de ejecutar su propio entorno. Para conectarse al entorno compartido, cada cliente debe instalar y ejecutar su propio servicio de integración. Los clientes son responsables de lo siguiente:
- Crear y administrar wallet addresses para sus usuarios (por ejemplo, sus consumidores).
- Enviar y recibir pagos.
@@ -38,7 +38,7 @@ Un cliente es una ASE que se conecta a una instancia compartida de Rafiki en lug
## Beneficios de la multitenencia
- El mantenimiento centralizado permite a los operadores realizar actualizaciones una sola vez para todos los clientes.
-- La incorporación mejorada permite que las nuevas ASE se conecten al entorno compartido sin tener que implementar su propia instancia de Rafiki.
+- La incorporación mejorada permite que las nuevas FSP se conecten al entorno compartido sin tener que implementar su propia instancia de Rafiki.
- La administración simplificada ofrece a los operadores una forma rápida de agregar y eliminar clientes.
### Consideraciones clave
diff --git a/packages/documentation/src/content/docs/es/overview/concepts/telemetry.mdx b/packages/documentation/src/content/docs/es/overview/concepts/telemetry.mdx
index 73864b54e8..4bce5bda07 100644
--- a/packages/documentation/src/content/docs/es/overview/concepts/telemetry.mdx
+++ b/packages/documentation/src/content/docs/es/overview/concepts/telemetry.mdx
@@ -20,7 +20,7 @@ Nuestros objetivos son:
### Privacidad y opcionalidad
-La privacidad es una preocupación primordial para Interledger Foundation. La función de telemetría de Rafiki está diseñada para proporcionar información valiosa de la red sin vulnerar la privacidad ni facilitar actividades maliciosas por parte de las ASE. Consulte la sección [Privacidad](#privacidad) a continuación para obtener más información.
+La privacidad es una preocupación primordial para Interledger Foundation. La función de telemetría de Rafiki está diseñada para proporcionar información valiosa de la red sin vulnerar la privacidad ni facilitar actividades maliciosas por parte de las FSP (financial service provider). Consulte la sección [Privacidad](#privacidad) a continuación para obtener más información.
Actualmente, la función de telemetría está habilitada de forma predeterminada en los entornos de prueba (entornos que no manejan dinero real). Cuando está activa, la función transmite métricas al recopilador de testnet. Puede optar por compartir sus métricas con un recopilador de livenet cuando opere en un entorno de livenet de producción (con dinero real). Independientemente del entorno, también puede optar por desactivar la telemetría por completo. Revise las [variables de entorno de telemetría](#variables-de-entorno-de-telemetría) para obtener más información.
@@ -63,10 +63,10 @@ Interledger Foundation inicialmente utilizó Grafana alojado en Amazon, pero no
Para fines de telemetría, todos los importes recopilados por Rafiki instrumentado deben convertirse a una moneda base.
:::caution[Justificación de privacidad]
-Si solo dos ASE están interconectadas mediante una moneda distinta del USD y recopilamos datos en esa moneda, sería fácil determinar los volúmenes transferidos entre esas dos ASE. Para mantener la privacidad, convertimos todos los importes a una moneda base.
+Si solo dos FSP están interconectadas mediante una moneda distinta del USD y recopilamos datos en esa moneda, sería fácil determinar los volúmenes transferidos entre esas dos FSP. Para mantener la privacidad, convertimos todos los importes a una moneda base.
:::
-Si una ASE no proporciona el tipo de cambio necesario para una transacción, la solución de telemetría igualmente convierte el importe a la moneda base utilizando tipos de cambio externos. Una función Lambda en AWS recupera y almacena los tipos de cambio externos. La función se activa mediante un evento diario de `CloudWatch` y almacena los tipos de cambio en un bucket público de S3. El bucket de S3 no tiene control de versiones, y los datos se sobrescriben diariamente para garantizar aún más la privacidad.
+Si una FSP no proporciona el tipo de cambio necesario para una transacción, la solución de telemetría igualmente convierte el importe a la moneda base utilizando tipos de cambio externos. Una función Lambda en AWS recupera y almacena los tipos de cambio externos. La función se activa mediante un evento diario de `CloudWatch` y almacena los tipos de cambio en un bucket público de S3. El bucket de S3 no tiene control de versiones, y los datos se sobrescriben diariamente para garantizar aún más la privacidad.
### Instrumentación
@@ -118,7 +118,7 @@ El ruido, seleccionado de la distribución de Laplace, se genera utilizando este
### Conversión de moneda
-Otro factor que oculta los datos confidenciales es la conversión de moneda. En las transacciones entre distintas monedas, usted, como ASE, proporciona los tipos de cambio internamente. De este modo, los tipos de cambio no se pueden correlacionar con una transacción individual. Si no proporciona o no puede proporcionar los tipos de cambio necesarios, se utiliza una API externa para los tipos de cambio. En este caso, los tipos de cambio obtenidos se sobrescriben con frecuencia, sin control de versiones ni acceso al historial. Esto introduce una capa adicional de ruido y protege aún más la privacidad de las transacciones.
+Otro factor que oculta los datos confidenciales es la conversión de moneda. En las transacciones entre distintas monedas, usted, como FSP, proporciona los tipos de cambio internamente. De este modo, los tipos de cambio no se pueden correlacionar con una transacción individual. Si no proporciona o no puede proporcionar los tipos de cambio necesarios, se utiliza una API externa para los tipos de cambio. En este caso, los tipos de cambio obtenidos se sobrescriben con frecuencia, sin control de versiones ni acceso al historial. Esto introduce una capa adicional de ruido y protege aún más la privacidad de las transacciones.
### Valores experimentales de las transacciones al utilizar el algoritmo
diff --git a/packages/documentation/src/content/docs/es/overview/overview.mdx b/packages/documentation/src/content/docs/es/overview/overview.mdx
index 6045b6730e..75403890bd 100644
--- a/packages/documentation/src/content/docs/es/overview/overview.mdx
+++ b/packages/documentation/src/content/docs/es/overview/overview.mdx
@@ -7,7 +7,7 @@ import { Card, CardGrid } from '@astrojs/starlight/components'
Implementar y mantener la pila del [Protocolo Interledger (ILP)](#interledger) por cuenta propia puede resultar difícil y llevar mucho tiempo. Rafiki facilita la integración con la red Interledger sin necesidad de desarrollar y mantener sus propias implementaciones.
-Rafiki es un software de código abierto mantenido por un equipo especializado y disponible de forma gratuita para cualquier [Review the checklist >](/integration/requirements/overview)
[Create a tenant >](/integration/requirements/tenants)
[Create a tenant >](/integration/requirements/tenants)
[Create an asset >](/integration/requirements/assets)
[Create a wallet address >](/integration/requirements/wallet-addresses)
[Create a wallet address >](/integration/requirements/wallet-addresses)
[Specify a webhook endpoint >](/integration/requirements/webhook-events)
[createQuote mutation >](https://rafiki.dev/apis/graphql/backend#mutation-createQuote)
[createOutgoingPayment mutation >](https://rafiki.dev/apis/graphql/backend#mutation-createOutgoingPayment)
[createOutgoingPayment mutation >](https://rafiki.dev/apis/graphql/backend#mutation-createOutgoingPayment)
[Webhook events >](/integration/requirements/webhook-events)
[Webhook events >](/integration/requirements/webhook-events)
- SPSP
- Open Payments APIs
- GraphQL Admin APIs
- STREAM endpoint
- A peer is another ASE that you connect with via Interledger who is
+ A peer is another FSP that you connect with via Interledger who is
likely running their own Rafiki instance. If you are using Rafiki solely
for transfers between accounts on your own ledger, peers aren't
required. Otherwise, you must [add at least one
diff --git a/packages/documentation/src/content/docs/integration/requirements/peers.mdx b/packages/documentation/src/content/docs/integration/requirements/peers.mdx
index 9f0fc5f2b2..d689b4ca8c 100644
--- a/packages/documentation/src/content/docs/integration/requirements/peers.mdx
+++ b/packages/documentation/src/content/docs/integration/requirements/peers.mdx
@@ -9,7 +9,7 @@ import { LinkOut } from '@interledger/docs-design-system'
import { Badge } from '@astrojs/starlight/components'
import TenantIdHmacNote from '/src/content/docs/partials/_tenant-id-hmac-note.mdx'
-To join the Interledger network and be able to send and receive payments, you must add one or more peers to your Rafiki instance. Peering establishes the connections needed for your Rafiki instance to interact with another account servicing entity (ASE). The purpose of this guide is to help you set up and manage peers.
+To join the Interledger network and be able to send and receive payments, you must add one or more peers to your Rafiki instance. Peering establishes the connections needed for your Rafiki instance to interact with another financial service provider (FSP). The purpose of this guide is to help you set up and manage peers.
While this guide focuses on the conceptual and technical steps of adding and managing peers via the Backend Admin API, the Rafiki Admin app offers the same capabilities in a user-friendly interface.
@@ -28,10 +28,10 @@ Tenants can view, edit, and delete only their own peers. They can't create peers
## Perform prerequisites
:::note
-Peering isn't required unless you want to participate in transactions with another ASE on the Interledger network. For foundational peering concepts, refer to the Peers section of [Interledger Concepts](/overview/concepts/interledger/#peers).
+Peering isn't required unless you want to participate in transactions with another FSP on the Interledger network. For foundational peering concepts, refer to the Peers section of [Interledger Concepts](/overview/concepts/interledger/#peers).
:::
-Before adding a peer, you and the account servicing entity you intend to peer with must both:
+Before adding a peer, you and the FSP you intend to peer with must both:
### Run an Interledger connector
@@ -65,7 +65,7 @@ While you can deposit an `initialLiquidity` for your peer, you can also deposit
### Define a maxPacketAmount value
-The `maxPacketAmount` specifies the maximum packet size you are willing to accept from the peer. Your peer's `maxPacketAmount` value doesn't need to match, as this value is independently set by each ASE. If omitted, payments won't be broken into smaller packets.
+The `maxPacketAmount` specifies the maximum packet size you are willing to accept from the peer. Your peer's `maxPacketAmount` value doesn't need to match, as this value is independently set by each FSP. If omitted, payments won't be broken into smaller packets.
## Set up peering in Rafiki
diff --git a/packages/documentation/src/content/docs/integration/requirements/tenants.mdx b/packages/documentation/src/content/docs/integration/requirements/tenants.mdx
index a8459b3079..156fe13e54 100644
--- a/packages/documentation/src/content/docs/integration/requirements/tenants.mdx
+++ b/packages/documentation/src/content/docs/integration/requirements/tenants.mdx
@@ -7,7 +7,7 @@ tableOfContents:
import { Tabs, TabItem } from '@astrojs/starlight/components'
import { LinkOut } from '@interledger/docs-design-system'
-In Rafiki, a tenant represents an isolated environment for an account servicing entity (ASE). Each tenant has its own set of resources, such as assets, peers, and wallet addresses, and its own configuration settings. This allows multiple ASEs to share a single Rafiki instance while maintaining data isolation and security. The purpose of this guide is to help you set up and manage tenants.
+In Rafiki, a tenant represents an isolated environment for a financial service provider. Each tenant has its own set of resources, such as assets, peers, and wallet addresses, and its own configuration settings. This allows multiple FSPs to share a single Rafiki instance while maintaining data isolation and security. The purpose of this guide is to help you set up and manage tenants.
While this guide focuses on operators managing tenants from the Backend Admin API, the Rafiki Admin app offers the same capabilities in a user-friendly interface.
diff --git a/packages/documentation/src/content/docs/integration/requirements/wallet-addresses.mdx b/packages/documentation/src/content/docs/integration/requirements/wallet-addresses.mdx
index f87c43d4ce..96ea1af9b3 100644
--- a/packages/documentation/src/content/docs/integration/requirements/wallet-addresses.mdx
+++ b/packages/documentation/src/content/docs/integration/requirements/wallet-addresses.mdx
@@ -8,22 +8,23 @@ import { Tabs, TabItem } from '@astrojs/starlight/components'
import { LinkOut } from '@interledger/docs-design-system'
import TenantIdHmacNote from '/src/content/docs/partials/_tenant-id-hmac-note.mdx'
-Each payment account belonging to your users (for example, your customers) must have at least one associated wallet address for the account to be able to send and receive payments over Interledger and Open Payments. A wallet address serves as a publicly shareable standardized ID for a payment account. Each wallet address belongs to a specific tenant.
+Each of your customers' payment accounts must be associated with at least one wallet address for the account to be able to send and receive payments over Interledger and Open Payments. A wallet address serves as a publicly shareable standardized ID for a payment account.
-**Permissions**
+Wallet addresses are created and hosted in Rafiki. However, the mapping of a wallet address to a customer account stays with you and is never stored in Rafiki's database tables.
-- Operators can create wallet addresses for any tenant
-- Tenants can only create wallet addresses for themselves
+:::note[Permissions]
+Each wallet address belongs to a specific tenant. Operators can create wallet addresses for any tenant. Tenants can only create wallet addresses for themselves.
+:::
-:::note[Wallet address requirements]
+## Wallet address requirements
- Your Rafiki instance must be set up with at least one asset before wallet addresses can be created as each wallet address must have an asset assigned to it.
+- Wallet address structure is determined by the financial service provider (FSP). Consider whether your chosen naming conventions could disclose personal data. For example, choosing to issue addresses using first and last names.
- Wallet address URLs are treated as case-insensitive, meaning that both lowercase and uppercase variations of the same address will be recognized as identical.
-- Operators must configure a wallet address prefix for each tenant. When creating wallet addresses, tenants are restricted to using this prefix.
-
-:::
-
-Once the wallet address base (`WALLET_ADDRESS_URL`) is set for a tenant, it can't be changed.
+- Operators must configure a wallet address base for each tenant. When creating wallet addresses, tenants are restricted to using this base.
+ :::note
+ Once the wallet address base (`WALLET_ADDRESS_URL`) is set for a tenant, it can't be changed.
+ :::
## Create wallet addresses
diff --git a/packages/documentation/src/content/docs/integration/requirements/webhook-events.mdx b/packages/documentation/src/content/docs/integration/requirements/webhook-events.mdx
index 481e2e4481..501c6edbe9 100644
--- a/packages/documentation/src/content/docs/integration/requirements/webhook-events.mdx
+++ b/packages/documentation/src/content/docs/integration/requirements/webhook-events.mdx
@@ -237,10 +237,10 @@ If a non-200 status is returned, indicating an error, or the request times out,
receivedAmount: $10
- ASE->>R: Backend Admin API call: createIncomingPaymentWithdrawal
- R-->>ASE: success: true
- ASE->>ASE: Credit recipient's account with $10
+ R->>FSP: Fires incoming_payment.completed event to webhook endpoint,
receivedAmount: $10
+ FSP->>R: Backend Admin API call: createIncomingPaymentWithdrawal
+ R-->>FSP: success: true
+ FSP->>FSP: Credit recipient's account with $10
`}
/>
@@ -274,14 +274,14 @@ The incoming payment can either complete, receive a partial payment, or expire.
receivedAmount: $10
- ASE->>R: Backend Admin API call: createIncomingPaymentWithdrawal
- R-->>ASE: success: true
- ASE->>ASE: Credit recipient's account with $10
- ASE->>R: Backend Admin API call: postLiquidityWithdrawal
- R-->>ASE: success: true
+ participant FSP as Financial service provider
+
+ R->>FSP: Fires incoming_payment.completed event to webhook endpoint,
receivedAmount: $10
+ FSP->>R: Backend Admin API call: createIncomingPaymentWithdrawal
+ R-->>FSP: success: true
+ FSP->>FSP: Credit recipient's account with $10
+ FSP->>R: Backend Admin API call: postLiquidityWithdrawal
+ R-->>FSP: success: true
R->>R: Two-phase transfer completed
`}
@@ -298,17 +298,17 @@ The `incoming_payment.completed` event indicates the payment completed either au
receivedAmount: $2.55
- ASE->>R: Backend Admin API call: createIncomingPaymentWithdrawal
- R-->>ASE: success: true
- ASE->>ASE: Credit recipient's account with $2.55
+ R->>FSP: Fires incoming_payment.expired event to webhook endpoint,
receivedAmount: $2.55
+ FSP->>R: Backend Admin API call: createIncomingPaymentWithdrawal
+ R-->>FSP: success: true
+ FSP->>FSP: Credit recipient's account with $2.55
`}
/>
@@ -383,17 +383,17 @@ An outgoing payment for \$12 was created.
debitAmount: $12
- ASE->>ASE: Checks that sender's account has sufficient funds
+ R->>FSP: Fires outgoing_payment.created event to webhook endpoint,
debitAmount: $12
+ FSP->>FSP: Checks that sender's account has sufficient funds
alt Account has sufficient funds
- ASE->>ASE: Put hold of $12 on sender's account
- ASE->>R: Backend Admin API call: depositOutgoingPaymentLiquidity
- R-->>ASE: success: true
+ FSP->>FSP: Put hold of $12 on sender's account
+ FSP->>R: Backend Admin API call: depositOutgoingPaymentLiquidity
+ R-->>FSP: success: true
else Account has insufficient funds
- ASE->>R: Backend Admin API call: cancelOutgoingPayment,
Reason: insufficient funds
- R-->>ASE: success: true
+ FSP->>R: Backend Admin API call: cancelOutgoingPayment,
Reason: insufficient funds
+ R-->>FSP: success: true
end
`}
@@ -414,12 +414,12 @@ If the sender has insufficient funds or if the payment should otherwise not be f
debitAmount: $12, sentAmount: $11.50
- ASE->>R: Backend Admin API call: createOutgoingPaymentWithdrawal
- R-->>ASE: success: true
- ASE->>ASE: Remove hold and deduct $12 from sender's account,
credit your account with $0.50
+ R->>FSP: Fires outgoing_payment.completed event to webhook endpoint,
debitAmount: $12, sentAmount: $11.50
+ FSP->>R: Backend Admin API call: createOutgoingPaymentWithdrawal
+ R-->>FSP: success: true
+ FSP->>FSP: Remove hold and deduct $12 from sender's account,
credit your account with $0.50
`}
/>
@@ -428,14 +428,14 @@ If the sender has insufficient funds or if the payment should otherwise not be f
debitAmount: $12, sentAmount: $11.50
- ASE->>R: Backend Admin API call: createOutgoingPaymentWithdrawal
- R-->>ASE: success: true
- ASE->>ASE: Remove hold and deduct $12 from sender's account,
credit your account with $0.50
- ASE->>R: Backend Admin API call: postLiquidityWithdrawal
- R-->>ASE: success: true
+ participant FSP as Financial service provider
+
+ R->>FSP: Fires outgoing_payment.completed event to webhook endpoint,
debitAmount: $12, sentAmount: $11.50
+ FSP->>R: Backend Admin API call: createOutgoingPaymentWithdrawal
+ R-->>FSP: success: true
+ FSP->>FSP: Remove hold and deduct $12 from sender's account,
credit your account with $0.50
+ FSP->>R: Backend Admin API call: postLiquidityWithdrawal
+ R-->>FSP: success: true
R->>R: Two-phase transfer complete
`}
@@ -457,12 +457,12 @@ An outgoing payment for \$12 failed. \$8 was sent successfully.
debitAmount: $12, sentAmount: $8
- ASE->>R: Backend Admin API call: createOutgoingPaymentWithdrawal
- R-->>ASE: success: true
- ASE->>ASE: Remove hold and deduct $8 from the sender's account
+ R->>FSP: Fires outgoing_payment.failed event to webhook endpoint,
debitAmount: $12, sentAmount: $8
+ FSP->>R: Backend Admin API call: createOutgoingPaymentWithdrawal
+ R-->>FSP: success: true
+ FSP->>FSP: Remove hold and deduct $8 from the sender's account
`}
/>
@@ -492,11 +492,11 @@ The wallet address, `https://wallet.example.com/carla_garcia` was requested but
wallet address: https://wallet.example.com/carla_garcia
- ASE->>R: Backend Admin API call: createWalletAddress,
url: https://wallet.example.com/carla_garcia,
public name: Carla Eva Garcia
- R-->>ASE: success: true
+ R->>FSP: Fires wallet_address.not_found event to webhook endpoint,
wallet address: https://wallet.example.com/carla_garcia
+ FSP->>R: Backend Admin API call: createWalletAddress,
url: https://wallet.example.com/carla_garcia,
public name: Carla Eva Garcia
+ R-->>FSP: success: true
`}
/>
@@ -525,12 +525,12 @@ A wallet address received a Web Monetization payment of \$0.33
receivedAmount: $0.33
- ASE->>R: Backend Admin API call: createWalletAddressWithdrawal
- R-->>ASE: success: true
- ASE->>ASE: Credit recipient's account with $0.33
+ R->>FSP: Fires wallet_address.web_monetization event to webhook endpoint,
receivedAmount: $0.33
+ FSP->>R: Backend Admin API call: createWalletAddressWithdrawal
+ R-->>FSP: success: true
+ FSP->>FSP: Credit recipient's account with $0.33
`}
/>
@@ -559,11 +559,11 @@ Your asset liquidity for USD (asset scale: 2) drops below \$100.00.
asset: USD (scale: 2, id: "abc")
- ASE->>R: Backend Admin API call: depositAssetLiquidity
- R-->>ASE: success: true
+ R->>FSP: Fires asset.liquidity_low event to webhook endpoint,
asset: USD (scale: 2, id: "abc")
+ FSP->>R: Backend Admin API call: depositAssetLiquidity
+ R-->>FSP: success: true
`}
/>
@@ -592,11 +592,11 @@ The liquidity for your peer, Happy Life Bank, drops below \$100.00 USD.
peer: Happy Life Bank (asset: "USD", scale: 2, id: "abc")
- ASE->>R: Backend Admin API call: depositPeerLiquidity
- R-->>ASE: success: true
+ R->>FSP: Fires peer.liquidity_low event to webhook endpoint,
peer: Happy Life Bank (asset: "USD", scale: 2, id: "abc")
+ FSP->>R: Backend Admin API call: depositPeerLiquidity
+ R-->>FSP: success: true
`}
/>
diff --git a/packages/documentation/src/content/docs/overview/concepts/account-servicing-entity.mdx b/packages/documentation/src/content/docs/overview/concepts/account-servicing-entity.mdx
deleted file mode 100644
index 53335f78ce..0000000000
--- a/packages/documentation/src/content/docs/overview/concepts/account-servicing-entity.mdx
+++ /dev/null
@@ -1,31 +0,0 @@
----
-title: Account servicing entity (ASE)
----
-
-An account servicing entity (ASE) is a regulated entity that provides and maintains payment accounts for its customers. Examples of ASEs include banks, digital wallet providers, and mobile money providers.
-
-As regulated entities, ASEs are subject to the laws, rules, and regulations of their jurisdictions. As such, Rafiki should **not** be used in production environments by non-regulated entities.
-
-## Responsibilities and obligations
-
-
-
-### AML (Anti-money laundering)
-
-ASEs follow anti-money laundering laws and regulations to detect and prevent money laundering and other suspicious financial activities.
-
-### KYC/KYB (Know your customer/business)
-
-KYC and KYB practices ensure ASEs verify the identities of their customers by collecting IDs and proof of address, verifying business registrations, checking against sanctions lists, and other processes.
-
-### User account management
-
-ASEs manage the creation, upkeep, and security of their customers' accounts and balances therein. Similarly, they're responsible for authenticating their customers and providing secure channels for them to interact with their accounts via mobile apps, websites, or other interfaces.
-
-### Ledger
-
-As ASEs handle deposits and withdrawals through external payment methods (like bank transfers, credit cards, and other services) they must record all transactions and balance information in their ledger.
diff --git a/packages/documentation/src/content/docs/overview/concepts/accounting.mdx b/packages/documentation/src/content/docs/overview/concepts/accounting.mdx
index 5287e2f91a..62c8f8a235 100644
--- a/packages/documentation/src/content/docs/overview/concepts/accounting.mdx
+++ b/packages/documentation/src/content/docs/overview/concepts/accounting.mdx
@@ -230,11 +230,11 @@ A single-phase transfer posts funds to accounts immediately when the transfer is
liquidity account (reserve funds pending)
- ASE->>ASE: Credits the recipient's account by the payment amount
- ASE->>Rafiki: Resolve funds (post)
+ Rafiki->>FSP: Fires webhook event when incoming payment completes
+ FSP->>Rafiki: Withdraws payment amount from incoming payment
liquidity account (reserve funds pending)
+ FSP->>FSP: Credits the recipient's account by the payment amount
+ FSP->>Rafiki: Resolve funds (post)
Rafiki->>Rafiki: Two-phase transfer complete
`}
/>
diff --git a/packages/documentation/src/content/docs/overview/concepts/clearing-settlement.mdx b/packages/documentation/src/content/docs/overview/concepts/clearing-settlement.mdx
index 2f8661193f..fba00e7aef 100644
--- a/packages/documentation/src/content/docs/overview/concepts/clearing-settlement.mdx
+++ b/packages/documentation/src/content/docs/overview/concepts/clearing-settlement.mdx
@@ -6,25 +6,25 @@ import { LinkOut } from '@interledger/docs-design-system'
## Clearing
-When a payment is made over traditional banking rails, the money doesn't move instantly. First, there are checks to confirm that the money exists and can be transferred. Clearing networks are responsible for exchanging messages between ASEs to facilitate these checks. This process is called clearing. When a payment successfully clears, it means the payer's ASE has an obligation to the payee's ASE.
+When a payment is made over traditional banking rails, the money doesn't move instantly. First, there are checks to confirm that the money exists and can be transferred. Clearing networks are responsible for exchanging messages between financial service providers (FSPs) to facilitate these checks. This process is called clearing. When a payment successfully clears, it means the payer's FSP has an obligation to the payee's FSP.
The [Interledger Protocol (ILP)](/overview/concepts/interledger) isn't a traditional clearing network, but does function in a similar way.
-- ASEs that implement the protocol must become [peers](/integration/requirements/peers) to transact with one another. This is comparable to traditional banking, where ASEs must use the same clearing network. An ASE can't use Interledger to transact with another ASE unless they have both implemented the protocol and have peered with one another.
-- Peered ASEs exchange ILP packets, which are packets of value that contain transaction information. ILP packets are akin to the messages exchanged during the traditional clearing process.
+- FSPs that implement the protocol must become [peers](/integration/requirements/peers) to transact with one another. This is comparable to traditional banking, where FSPs must use the same clearing network. An FSP can't use Interledger to transact with another FSP unless they have both implemented the protocol and have peered with one another.
+- Peered FSPs exchange ILP packets, which are packets of value that contain transaction information. ILP packets are akin to the messages exchanged during the traditional clearing process.
- The successful exchange of ILP packets between peers creates obligations between them that must be settled. The receipt of a fulfilled ILP packet is basically a conditional IOU—a promise to pay—that affects the financial accounting balances between the peers.
You can read more about clearing as it relates to ILP in the 
+
+### AML (Anti-money laundering)
+
+FSPs follow anti-money laundering laws and regulations to detect and prevent money laundering and other suspicious financial activities.
+
+### KYC/KYB (Know your customer/business)
+
+KYC and KYB practices ensure FSPs verify the identities of their customers by collecting IDs and proof of address, verifying business registrations, checking against sanctions lists, and other processes.
+
+### User account and data management
+
+FSPs are responsible for:
+
+- Managing the creation, storage, upkeep, and security of their customers' accounts and balances therein.
+- Authenticating their customers and providing secure channels for them to interact with their accounts via mobile apps, websites, or other interfaces.
+- Storing and maintaining their own wallet address-to-customer account mapping. Rafiki hosts [wallet addresses](/integration/requirements/wallet-addresses) for account discoverability but doesn't store any link between an address and a customer account.
+
+### Ledgers
+
+As FSPs handle deposits and withdrawals through external payment methods (like bank transfers, credit cards, and other services) they must record all transactions and balance information in their ledger.
diff --git a/packages/documentation/src/content/docs/overview/concepts/multi-tenancy.mdx b/packages/documentation/src/content/docs/overview/concepts/multi-tenancy.mdx
index 4e3a67db68..348bfc1632 100644
--- a/packages/documentation/src/content/docs/overview/concepts/multi-tenancy.mdx
+++ b/packages/documentation/src/content/docs/overview/concepts/multi-tenancy.mdx
@@ -2,9 +2,9 @@
title: Multi-tenancy
---
-Multi-tenancy is an architectural approach that enables a single Rafiki instance to service multiple account servicing entities (ASEs). This allows organizations to share application services and database resources while maintaining data isolation and security. By implementing multi-tenancy, Rafiki simplifies the integration process for ASEs, making onboarding faster and easier.
+Multi-tenancy is an architectural approach that enables a single Rafiki instance to service multiple financial service providers (FSPs). This allows organizations to share application services and database resources while maintaining data isolation and security. By implementing multi-tenancy, Rafiki simplifies the integration process for FSPs, making onboarding faster and easier.
-In a multi-tenant environment, the entity responsible for managing a Rafiki instance that serves multiple ASEs is called an **operator**. Each ASE that uses the shared Rafiki instance is called a **tenant**.
+In a multi-tenant environment, the entity responsible for managing a Rafiki instance that serves multiple FSPs is called an **operator**. Each FSP that uses the shared Rafiki instance is called a **tenant**.
## Operator and tenant roles and responsibilities
@@ -28,7 +28,7 @@ Tenants are added through the Backend Admin API or the [Rafiki Admin application
### Tenant
-A tenant is an ASE that connects to a shared Rafiki instance rather than running its own environment. To connect to the shared environment, each tenant must install and run their own integration service. Tenants are responsible for the following:
+A tenant is an FSP that connects to a shared Rafiki instance rather than running its own environment. To connect to the shared environment, each tenant must install and run their own integration service. Tenants are responsible for the following:
- Creating and managing wallet addresses for their users (for example, their customers)
- Sending and receiving payments
@@ -38,7 +38,7 @@ A tenant is an ASE that connects to a shared Rafiki instance rather than running
## Benefits of multi-tenancy
- Centralized maintenance lets operators perform updates once for all tenants.
-- Enhanced onboarding allows new ASEs to connect to the shared environment without deploying their own Rafiki instance.
+- Enhanced onboarding allows new FSPs to connect to the shared environment without deploying their own Rafiki instance.
- Simplified administration provides operators with a quick way to add and remove tenants.
### Key considerations
diff --git a/packages/documentation/src/content/docs/overview/concepts/telemetry.mdx b/packages/documentation/src/content/docs/overview/concepts/telemetry.mdx
index 90ec97da9d..0992921f04 100644
--- a/packages/documentation/src/content/docs/overview/concepts/telemetry.mdx
+++ b/packages/documentation/src/content/docs/overview/concepts/telemetry.mdx
@@ -20,7 +20,7 @@ Our goals are to:
### Privacy and optionality
-Privacy is a paramount concern for the Interledger Foundation. Rafiki’s telemetry feature is designed to provide valuable network insights without violating privacy or aiding malicious ASEs. Review the [Privacy](#privacy) section below for more information.
+Privacy is a paramount concern for the Interledger Foundation. Rafiki's telemetry feature is designed to provide valuable network insights without violating privacy or aiding malicious financial service providers (FSPs). Review the [Privacy](#privacy) section below for more information.
The telemetry feature is currently enabled by default on test environments (environments not dealing with real money). When active, the feature transmits metrics to the testnet collector. You can opt in to sharing your metrics with a livenet collector when operating in a production livenet environment (with real money). Regardless of environment, you can also opt-out of telemetry completely. Review the [telemetry environment variables](#telemetry-environment-variables) for more information.
@@ -63,10 +63,10 @@ The Interledger Foundation initially used Amazon-hosted Grafana which didn't mee
For telemetry purposes, all amounts collected by instrumented Rafiki should be converted to a base currency.
:::caution[Privacy reasoning]
-If only two ASEs are peered over a non-USD currency and we collect data in that currency, it would be easy to determine the volumes moved between those two ASEs. To maintain privacy, we convert all amounts to a base currency.
+If only two FSPs are peered over a non-USD currency and we collect data in that currency, it would be easy to determine the volumes moved between those two FSPs. To maintain privacy, we convert all amounts to a base currency.
:::
-If an ASE doesn't provide the necessary exchange rate for a transaction, the telemetry solution still converts the amount to the base currency using external exchange rates. A Lambda function on AWS retrieves and stores the external exchange rates. The function is triggered by a daily `CloudWatch` event and stores the rates in a public S3 bucket. The S3 bucket doesn't have versioning, and the data is overwritten daily to further ensure privacy.
+If an FSP doesn't provide the necessary exchange rate for a transaction, the telemetry solution still converts the amount to the base currency using external exchange rates. A Lambda function on AWS retrieves and stores the external exchange rates. The function is triggered by a daily `CloudWatch` event and stores the rates in a public S3 bucket. The S3 bucket doesn't have versioning, and the data is overwritten daily to further ensure privacy.
### Instrumentation
@@ -90,7 +90,9 @@ The current implementation only collects metrics on the SENDING side of a transa
## Privacy
-Rafiki telemetry is designed with a strong emphasis on privacy. The system anonymizes user data and refrains from collecting identifiable information. Since transactions can originate from any user to a Rafiki instance, the privacy measures are implemented directly at the source (each Rafiki instance). This means that at the individual level, the data is already anonymous as single Rafiki instances service transactions for multiple users.
+Rafiki telemetry is designed with a strong emphasis on privacy. It's enabled by default on test environments and is opt-in on production deployments.
+
+The system anonymizes user data and refrains from collecting identifiable information. Since transactions can originate from any user to a Rafiki instance, the privacy measures are implemented directly at the source (each Rafiki instance). This means that at the individual level, the data is already anonymous as single Rafiki instances service transactions for multiple users.
### Differential privacy and local differential privacy (LDP)
@@ -118,7 +120,7 @@ The noise, selected from the Laplacian distribution, is then generated using thi
### Currency conversion
-Another factor that obscures sensitive data is currency conversion. In cross-currency transactions, exchange rates are provided by you, as the ASE, internally. As such, the exchange rates can't be correlated to an individual transaction. If you don't or can't provide the necessary rates, an external API for exchange rates is used. The obtained exchange rates are overwritten frequently in this case, with no versioning or history access. This introduces an additional layer of noise and further protects the privacy of the transactions.
+Another factor that obscures sensitive data is currency conversion. In cross-currency transactions, exchange rates are provided by you, as the FSP, internally. As such, the exchange rates can't be correlated to an individual transaction. If you don't or can't provide the necessary rates, an external API for exchange rates is used. The obtained exchange rates are overwritten frequently in this case, with no versioning or history access. This introduces an additional layer of noise and further protects the privacy of the transactions.
### Experimental transaction values when using the algorithm
diff --git a/packages/documentation/src/content/docs/overview/overview.mdx b/packages/documentation/src/content/docs/overview/overview.mdx
index ce3c5a68a6..3fdd6ea2e1 100644
--- a/packages/documentation/src/content/docs/overview/overview.mdx
+++ b/packages/documentation/src/content/docs/overview/overview.mdx
@@ -7,17 +7,17 @@ import { Card, CardGrid } from '@astrojs/starlight/components'
Implementing and maintaining the [Interledger Protocol (ILP)](#interledger) stack on your own can be difficult and time-consuming. Rafiki makes it easy to integrate with the Interledger network without needing to develop and maintain your own implementations.
-Rafiki is open-source software maintained by a dedicated team and freely available to any licensed