docs: fixes DOC-97

packages/documentation/astro.config.mjs

@@ -33,7 +33,7 @@ export default defineConfig({
     starlight({
       title: 'Rafiki',
       description:
-        'Rafiki is open source software that allows an Account Servicing Entity to enable Interledger functionality on its users’ accounts.',
+        'Rafiki is open source software that allows a financial service provider to enable Interledger functionality on user accounts.',
       customCss: [
         './node_modules/@interledger/docs-design-system/src/styles/teal-theme.css',
         './node_modules/@interledger/docs-design-system/src/styles/ilf-docs.css',
@@ -113,11 +113,8 @@ export default defineConfig({
               collapsed: true,
               items: [
                 {
-                  label: 'Account servicing entity',
-                  translations: {
-                    es: 'Entidad que administra la cuenta (ASE)'
-                  },
-                  link: '/overview/concepts/account-servicing-entity'
+                  label: 'Financial service provider',
+                  link: '/overview/concepts/financial-service-provider'
                 },
                 {
                   label: 'Multi-tenancy',
@@ -373,6 +370,10 @@ export default defineConfig({
               label: 'Webhook event types',
               link: '/resources/webhook-event-types'
             },
+            {
+              label: 'Further learning',
+              link: '/resources/further-learning'
+            },
             {
               label: 'Get involved',
               link: '/resources/get-involved'
@@ -382,21 +383,21 @@ export default defineConfig({
       ],
       plugins: [
         starlightLlmsTxt({
-          details: `Rafiki documentation is for Account Servicing Entities (ASEs) — regulated institutions such as banks, digital wallet providers, and mobile money operators — who want to run Rafiki to add Interledger and Open Payments functionality to their users' accounts. It is not documentation for an end-user product or a payment app.
+          details: `Rafiki documentation is for financial service providers (FSPs) — regulated institutions such as banks, digital wallet providers, and mobile money operators — who want to run Rafiki to add Interledger and Open Payments functionality to their users' accounts. It is not documentation for an end-user product or a payment app.
 
-Rafiki exposes several separate HTTP services rather than a single API surface: a GraphQL Admin API for managing the backend (peers, assets, wallet addresses, liquidity), a GraphQL Admin API for the auth service, an ILP connector, an auto-peering server, and REST APIs implementing the three parts of the Open Payments protocol. The backend serves the wallet address server and resource server together as a single Open Payments API. The auth service serves the authorization server (GNAP) separately. Questions about configuring or operating a Rafiki instance are answered by the Admin APIs; questions about initiating or receiving payments, or about grant negotiation, are answered by the Open Payments APIs, which are specified independently at openpayments.dev.
+          Rafiki exposes several separate HTTP services rather than a single API surface: a GraphQL Admin API for managing the backend (peers, assets, wallet addresses, liquidity), a GraphQL Admin API for the auth service, an ILP connector, an auto-peering server, and REST APIs implementing the three parts of the Open Payments protocol. The backend serves the wallet address server and resource server together as a single Open Payments API. The auth service serves the authorization server (GNAP) separately. Questions about configuring or operating a Rafiki instance are answered by the Admin APIs; questions about initiating or receiving payments, or about grant negotiation, are answered by the Open Payments APIs, which are specified independently at openpayments.dev.
 
-Rafiki supports two interchangeable accounting backends: TigerBeetle (the default, purpose-built for financial accounting) and PostgreSQL (an alternative for deployments that prefer a single database). Integration guidance does not change based on which is used.
+          Rafiki supports two interchangeable accounting backends: TigerBeetle (the default, purpose-built for financial accounting) and PostgreSQL (an alternative for deployments that prefer a single database). Integration guidance does not change based on which is used.
 
-This site publishes documentation for multiple Rafiki versions. Prefer the current/default version unless the user explicitly asks about an older release — content under a version prefix such as v1-beta describes a prior API surface and may no longer be accurate.
+          This site publishes documentation for multiple Rafiki versions. Prefer the current/default version unless the user explicitly asks about an older release — content under a version prefix such as v1-beta describes a prior API surface and may no longer be accurate.
 
-Key terminology notes:
+          Key terminology notes:
 
-- Rafiki is the reference implementation of the Open Payments protocol; ASEs deploy and operate it themselves, on their own infrastructure
-- Wallet addresses are URL-based identifiers for financial accounts — not cryptocurrency wallets
-- An Account Servicing Entity (ASE) is the regulated institution that holds and manages accounts on behalf of its users and runs Rafiki
-- Peering is the trust relationship two Rafiki instances (run by different ASEs) establish to exchange payments directly — distinct from a payment between two end users
-- Grants and GNAP (Grant Negotiation and Authorization Protocol) refer to Open Payments' authorization flow, distinct from OAuth`,
+          - Rafiki is the reference implementation of the Open Payments protocol; FSPs deploy and operate it themselves, on their own infrastructure
+          - Wallet addresses are URL-based identifiers for financial accounts — not cryptocurrency wallets
+          - A financial service provider (FSP) is the regulated institution that holds and manages accounts on behalf of its users and runs Rafiki
+          - Peering is the trust relationship two Rafiki instances (run by different FSPs) establish to exchange payments directly — distinct from a payment between two end users
+          - Grants and GNAP (Grant Negotiation and Authorization Protocol) refer to Open Payments' authorization flow, distinct from OAuth`,
           exclude: ['v1-beta/**'],
           optionalLinks: [
             {
@@ -416,7 +417,7 @@ Key terminology notes:
             {
               label: 'Overview and concepts',
               description:
-                'Introduction to Rafiki and core concepts such as account servicing entities, multi-tenancy, accounting, clearing and settlement, and Interledger',
+                'Introduction to Rafiki and core concepts such as financial service providers, multi-tenancy, accounting, clearing and settlement, and Interledger',
               paths: ['overview/**']
             },
             {

packages/documentation/src/content/docs/apis/graphql/admin-api-overview.mdx

@@ -4,7 +4,9 @@ title: Overview
 
 import { LinkOut } from '@interledger/docs-design-system'
 
-Rafiki provides two GraphQL APIs, described below. As described on <LinkOut href="https://graphql.org/">GraphQL.org</LinkOut>, GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL APIs are organized in terms of types and fields, not endpoints.
+Rafiki provides two GraphQL APIs, described below. These APIs must be private, meaning they're accessible only by the financial service provider.
+
+As described on <LinkOut href="https://graphql.org/">GraphQL.org</LinkOut>, GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL APIs are organized in terms of types and fields, not endpoints.
 
 ## Backend Admin API
 

packages/documentation/src/content/docs/es/index.mdx

@@ -4,7 +4,7 @@ description: Rafiki es un software de código abierto que ofrece a una Entidad d
 template: splash
 lastUpdated: false
 hero:
-  tagline: Rafiki es un software de código abierto que ofrece a una Entidad de Servicio de Cuentas (ASE) una solución eficiente para habilitar la funcionalidad de Interledger en las cuentas de sus usuarios.
+  tagline: Rafiki es un software de código abierto que ofrece a una Entidad de Servicio de Cuentas (financial service provider, FSP) una solución eficiente para habilitar la funcionalidad de Interledger en las cuentas de sus usuarios.
   actions:
     - text: Leer los documentos de Rafiki
       link: /es/overview/overview
@@ -19,7 +19,7 @@ import { Card, CardGrid, LinkCard } from '@astrojs/starlight/components'
 <CardGrid>
   <a class='card-link' href='/integration/playground/overview'>
     <Card title='¡Pruébelo!' icon='document'>
-      Pruebe Rafiki ejecutando dos ASE simuladas que se interconectan
+      Pruebe Rafiki ejecutando dos FSP simuladas que se interconectan
       automáticamente entre sí.
     </Card>
   </a>

packages/documentation/src/content/docs/es/overview/concepts/accounting.mdx

@@ -228,11 +228,11 @@ A single-phase transfer posts funds to accounts immediately when the transfer is
 <Mermaid
   graph={`sequenceDiagram
     participant R as Rafiki
-    participant ASE as Account servicing entity
+    participant FSP as Financial service provider
 
-    R->>ASE: Fires webhook event when incoming payment completes
-    ASE->>R: Withdraws payment amount from incoming payment liquidity account
-    ASE->>ASE: Credits the recipient's account by the payment amount
+    R->>FSP: Fires webhook event when incoming payment completes
+    FSP->>R: Withdraws payment amount from incoming payment liquidity account
+    FSP->>FSP: Credits the recipient's account by the payment amount
 
 `}
 />
@@ -248,10 +248,10 @@ A two-phase transfer moves funds in two stages.
 
 <Mermaid
   graph={`sequenceDiagram
-    Rafiki->>ASE: Fires webhook event when incoming payment completes
-    ASE->>Rafiki: Withdraws payment amount from incoming payment<br />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<br />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
   `}
 />

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 <LinkOut href='https://interledger.org/developers/rfcs/peering-clearing-settling/'>documentos para desarrolladores de Interledger</LinkOut>.
 
-Conceptualmente, Rafiki se sitúa en el nivel de compensación, pero no es una red de compensación. Es un software que permite implementar el Interledger Protocol de forma más rápida y sencilla. Rafiki utiliza ILP para [hacer un seguimiento de la liquidez](/es/overview/concepts/accounting) entre activos, pagos y pares. Una ASE aún debe conectar Rafiki con su sistema de backend existente y su libro mayor interno para la autenticación, la obtención de los tipos de cambio y la gestión de la liquidez. Por ejemplo, si un pago entrante se completa en Rafiki, el backend de la ASE debe acreditar los fondos en la cuenta del destinatario dentro de su propio sistema, independientemente de cómo lo implemente.
+Conceptualmente, Rafiki se sitúa en el nivel de compensación, pero no es una red de compensación. Es un software que permite implementar el Interledger Protocol de forma más rápida y sencilla. Rafiki utiliza ILP para [hacer un seguimiento de la liquidez](/es/overview/concepts/accounting) entre activos, pagos y pares. Una FSP aún debe conectar Rafiki con su sistema de backend existente y su libro mayor interno para la autenticación, la obtención de los tipos de cambio y la gestión de la liquidez. Por ejemplo, si un pago entrante se completa en Rafiki, el backend de la FSP debe acreditar los fondos en la cuenta del destinatario dentro de su propio sistema, independientemente de cómo lo implemente.
 
 En cualquier caso, aún no se ha producido ningún movimiento de dinero real.
 
 ## Liquidación
 
-En la banca tradicional, la liquidación es el cumplimiento de una obligación entre las ASE. Convierte la promesa de pago en un pago real mediante la transferencia de fondos reales. Esto ocurre a través de una red de liquidación compartida, como Fedwire en los Estados Unidos.
+En la banca tradicional, la liquidación es el cumplimiento de una obligación entre las FSP. Convierte la promesa de pago en un pago real mediante la transferencia de fondos reales. Esto ocurre a través de una red de liquidación compartida, como Fedwire en los Estados Unidos.
 
-Cuando la ASE del pagador liquida con la ASE del beneficiario, es muy probable que no esté transfiriendo dinero en efectivo de forma física. Lo más probable es que exista un intermediario, como un banco de reserva o un banco central, que mantenga cuentas para ambas ASE. El intermediario transfiere los fondos de una cuenta a la otra, acreditando y debitando las cuentas según sea necesario.
+Cuando la FSP del pagador liquida con la FSP del beneficiario, es muy probable que no esté transfiriendo dinero en efectivo de forma física. Lo más probable es que exista un intermediario, como un banco de reserva o un banco central, que mantenga cuentas para ambas FSP. El intermediario transfiere los fondos de una cuenta a la otra, acreditando y debitando las cuentas según sea necesario.
 
 Con Interledger, el concepto de liquidación no es tan diferente. Cada [par](/integration/requirements/peers) debe acordar un sistema de liquidación que se utilizará para cumplir con sus obligaciones mutuas. Sin embargo, ILP en sí mismo no es un sistema de liquidación. Esto significa que los pares deben tener alguna otra forma de cumplir con sus obligaciones e intercambiar valor. Los ejemplos pueden incluir el uso de un sistema de liquidación bruta en tiempo real, como Fedwire; una red de cámara de compensación automatizada (ACH); un servicio de transferencia de dinero o algún otro canal de pago. Puede obtener más información sobre la liquidación en relación con ILP en los <LinkOut href='https://interledger.org/developers/rfcs/settlement-engines/'>documentos para desarrolladores de Interledger</LinkOut>.