From ed94026db451fb9b969bcee9b81e0ef7063ddbd5 Mon Sep 17 00:00:00 2001 From: Oliver Eggert Date: Fri, 9 Dec 2022 15:48:17 -0800 Subject: [PATCH 1/8] Copy conceptual info out of send-a-check.md to checks.md --- .../concepts/transactions/payments/checks.md | 20 ++++++------------- .../use-checks/send-a-check.md | 2 ++ 2 files changed, 8 insertions(+), 14 deletions(-) diff --git a/content/concepts/transactions/payments/checks.md b/content/concepts/transactions/payments/checks.md index 8ac2ebe9a5..3aabc9247f 100644 --- a/content/concepts/transactions/payments/checks.md +++ b/content/concepts/transactions/payments/checks.md @@ -7,21 +7,11 @@ labels: --- # Checks -_(Added by the Checks amendment.)_ - -The Checks feature in the XRP Ledger allows users to create deferred payments that can be canceled or cashed by the intended recipients. Like personal paper checks, XRP Ledger Checks start with the sender of the funds creating a Check that specifies an amount and a recipient. The recipient cashes the check to pull the funds from the sender's account into the recipient's account. No money moves until the recipient cashes the Check. Because funds are not put on hold when the Check is created, cashing a Check can fail if the sender doesn't have enough funds when the recipient tries to cash it. If there's a failure cashing the check, the check's recipient can retry until the Check expires. +The Checks feature in the XRP Ledger enable users to create deferred payments that can be canceled or cashed by a recipients. Like personal paper checks, XRP Ledger Checks start with the sender of the funds creating a check that specifies an amount and a recipient. The recipient cashes the check to pull the funds from the sender's account into the recipient's account. Unlike an escrow or payment channel, funds aren't set aside when a check is created, so money only moves when the check is cashed. If the sender doesn't have the funds at the time a check is cashed, it'll fail. No money moves until the recipient cashes the Check. Because funds are not put on hold when the Check is created, cashing a Check can fail if the sender doesn't have enough funds when the recipient tries to cash it. If there's a failure cashing the check, the check's recipient can retry until the Check expires. XRP Ledger Checks may have expiration times after which they may no longer be cashed. If the recipient doesn't successfully cash the Check before it expires, the Check can no longer be cashed, but the object remains in the XRP Ledger until someone cancels it. Anyone may cancel the Check after it expires. Only the sender and recipient can cancel the Check before it expires. The Check object is removed from the Ledger when the sender successfully cashes the check or someone cancels it. -Checks have some similarities to [escrow](escrow.md) and [payment channels](payment-channels.md), but there are some important differences between those features and checks: - -* You can send [tokens](../../tokens/tokens.md) with checks. With payment channels and Escrow, you can only send XRP. - -* Checks do not lock up or set aside any funds. The XRP involved in payment channels and escrow cannot be spent until it is redeemed with a claim provided by the sender (payment channels), or released by an expiration or crypto-condition (escrow). - -* You can send XRP to yourself through escrow. You cannot send checks to yourself. - - +***TODO: Don't think this needs to be noted here. Is the behavior change documented on the reference page?*** **Note:** The Checks amendment changes the expiration behavior of the `OfferCreate` transaction. @@ -29,9 +19,11 @@ Checks have some similarities to [escrow](escrow.md) and [payment channels](paym ## Why Checks? -Traditional paper checks allow people to transfer funds without immediately exchanging physical currency. XRP Ledger Checks allow people to exchange funds asynchronously using a process that is familiar to and accepted by the banking industry. +- Checks allow people to exchange funds using a process that is familiar to and accepted by the banking industry. -XRP Ledger Checks also solve a problem that is unique to the XRP Ledger: they allow users to reject unwanted payments or accept only part of a payment. This is useful for institutions that need to be careful about accepting payments for compliance reasons. +- XRP Ledger Checks solve a problem that is unique to the Ledger: they enable users to reject unwanted payments or accept only part of a payment. This is useful for institutions that need to be careful about accepting payments for compliance reasons. + +- If your intended recipient blocks direct payments from stranger using deposit authorization, a check is a good alternative. ### Use Case: Payment Authorization diff --git a/content/tutorials/use-specialized-payment-types/use-checks/send-a-check.md b/content/tutorials/use-specialized-payment-types/use-checks/send-a-check.md index 867d5f84dc..fed92620a4 100644 --- a/content/tutorials/use-specialized-payment-types/use-checks/send-a-check.md +++ b/content/tutorials/use-specialized-payment-types/use-checks/send-a-check.md @@ -11,7 +11,9 @@ _Added by the [Checks amendment][]._ Sending a Check is like writing permission for an intended recipient to pull a payment from you. The outcome of this process is a [Check object in the ledger](check.html) which the recipient can cash later. + Moved to checks.md In many cases, you want to send a [Payment][] instead of a Check, since that delivers the money directly to the recipient in one step. However, if your intended recipient uses [DepositAuth](depositauth.html), you cannot send them Payments directly, so a Check is a good alternative. +<--> This tutorial uses the example of a fictitious company, BoxSend SG (whose XRP Ledger address is `rBXsgNkPcDN2runsvWmwxk3Lh97zdgo9za`) paying a fictitious cryptocurrency consulting company named Grand Payments (with XRP Ledger address `rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis`) for some consulting work. Grand Payments prefers be paid in XRP, but to simplify their taxes and regulation, only accepts payments they've explicitly approved. From 0cd043e33d10a36d27718a07927648dd6e0f0dd8 Mon Sep 17 00:00:00 2001 From: Oliver Eggert Date: Fri, 9 Dec 2022 16:01:28 -0800 Subject: [PATCH 2/8] Add note to merge look up check tutorials. --- .../use-checks/look-up-checks-by-recipient.md | 2 ++ .../use-checks/look-up-checks-by-sender.md | 2 ++ 2 files changed, 4 insertions(+) diff --git a/content/tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-recipient.md b/content/tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-recipient.md index f5b7a84455..9e0f7af8d4 100644 --- a/content/tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-recipient.md +++ b/content/tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-recipient.md @@ -7,6 +7,8 @@ labels: --- # Look Up Checks by Recipient +***TODO: Merge this with the look up checks by sender page.*** + _Added by the [Checks amendment][]._ This tutorial shows how to look up [Checks](checks.html) by their recipient. You may also want to [look up Checks by sender](look-up-checks-by-sender.html). diff --git a/content/tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-sender.md b/content/tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-sender.md index 2a065be411..ef7ff4233b 100644 --- a/content/tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-sender.md +++ b/content/tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-sender.md @@ -7,6 +7,8 @@ labels: --- # Look Up Checks by Sender +***TODO: Merge this with the look up checks by recipient page.*** + _Added by the [Checks amendment][]._ This tutorial shows how to look up [Checks](checks.html) by their sender. You may also want to [look up Checks by recipient](look-up-checks-by-recipient.html). From 02429025e73221ff4bd45d7f993a836c1d5e81c4 Mon Sep 17 00:00:00 2001 From: Oliver Eggert Date: Mon, 12 Dec 2022 09:10:51 -0800 Subject: [PATCH 3/8] Clean up checks conceptual info. --- .../concepts/transactions/payments/checks.md | 40 +++++++------------ 1 file changed, 14 insertions(+), 26 deletions(-) diff --git a/content/concepts/transactions/payments/checks.md b/content/concepts/transactions/payments/checks.md index 3aabc9247f..4af1065dd6 100644 --- a/content/concepts/transactions/payments/checks.md +++ b/content/concepts/transactions/payments/checks.md @@ -7,7 +7,7 @@ labels: --- # Checks -The Checks feature in the XRP Ledger enable users to create deferred payments that can be canceled or cashed by a recipients. Like personal paper checks, XRP Ledger Checks start with the sender of the funds creating a check that specifies an amount and a recipient. The recipient cashes the check to pull the funds from the sender's account into the recipient's account. Unlike an escrow or payment channel, funds aren't set aside when a check is created, so money only moves when the check is cashed. If the sender doesn't have the funds at the time a check is cashed, it'll fail. No money moves until the recipient cashes the Check. Because funds are not put on hold when the Check is created, cashing a Check can fail if the sender doesn't have enough funds when the recipient tries to cash it. If there's a failure cashing the check, the check's recipient can retry until the Check expires. +The Checks feature enables users to create deferred payments, similar to personal paper checks. Unlike an escrow or payment channel, funds aren't set aside when a check is created, so money only moves when the check is cashed. If the sender doesn't have the funds at the time a check is cashed, the transaction fails; recipients can retry failed transactions until the check expires. XRP Ledger Checks may have expiration times after which they may no longer be cashed. If the recipient doesn't successfully cash the Check before it expires, the Check can no longer be cashed, but the object remains in the XRP Ledger until someone cancels it. Anyone may cancel the Check after it expires. Only the sender and recipient can cancel the Check before it expires. The Check object is removed from the Ledger when the sender successfully cashes the check or someone cancels it. @@ -16,7 +16,7 @@ XRP Ledger Checks may have expiration times after which they may no longer be ca - +***TODO: Repurpose this into use cases.*** ## Why Checks? - Checks allow people to exchange funds using a process that is familiar to and accepted by the banking industry. @@ -25,6 +25,7 @@ XRP Ledger Checks may have expiration times after which they may no longer be ca - If your intended recipient blocks direct payments from stranger using deposit authorization, a check is a good alternative. +- Flexible check cashes. Specify a min amount up to maxamount to cash. ### Use Case: Payment Authorization @@ -35,27 +36,21 @@ XRP Ledger Checks may have expiration times after which they may no longer be ca **Solution:** Institutions can enable deposit authorization on their XRP Ledger accounts by setting the `asfDepositAuth` flag in an `AccountSet` transaction. This makes the account unable to receive Payment transactions. Accounts with Deposit Authorization enabled can only receive funds through Escrow, Payment Channels, or Checks. Checks are the most straightforward, familiar, and flexible way to transfer funds if Deposit Authorization is enabled. -## Usage +## Check Lifecycle -Checks typically have the lifecycle described below. +1. The sender creates a check using the `CheckCreate` transaction to define: + - The recipient. + - An expiration date. + - The maximum amount that can be debited from their account. - +2. After the transaction is processed, the XRP Ledger creates a `Check` object. The check can only be cancelled by the sender or receiver with a `CheckCancel` transaction. -[![Check flow diagram (successful cashing)](../../../../img/checks-happy-path.png)](../../../../img/checks-happy-path.png) - -**Step 1:** To create a Check, the sender submits a `CheckCreate` transaction and specifies the recipient (`Destination`), expiration time (`Expiration`), and maximum amount that may be debited from the sender's account (`SendMax`). - - -**Step 2:** After the CheckCreate transaction is processed, a Check object is created on the XRP Ledger. This object contains the properties of the check as defined by the transaction that created it. The object can only be modified by the sender (by canceling it with a `CheckCancel` transaction) or recipient (by canceling it or cashing it) before the expiration time passes. After the expiration time, anyone may cancel the Check. - -**Step 3:** To cash the check, the recipient submits a `CheckCash` transaction. The recipient has two options for cashing the check: - -* `Amount` — The recipient can use this option to specify an exact amount to cash. This may be useful for cases where the sender has padded the check to cover possible [transfer fees](../../tokens/transfer-fees.md) and the recipient wants to accept the exact amount on an invoice or other contract. - -* `DeliverMin` — The recipient can use this option to specify the minimum amount they are willing to receive from the Check. If the recipient uses this option, the XRP Ledger attempts to deliver as much as possible and always delivers at least this amount. The transaction fails if the amount that can be credited to the recipient is not at least the requested amount. - -If the sender has enough funds to cover the Check and the expiration time has not passed, the funds are debited from the sender's account and credited to the recipient's account, and the Check object is destroyed. +3. The recipient submits a `CheckCash` transaction that transfers the funds and destroys the `Check` object. + **Note:** Recipients have two options for cashing checks. + - Exact Amount: They specify an exact amount to cash that doesn't exceed the check maximum. + - Flexible Amount: They specify a minimum amount to cash and the XRP Ledger delivers as much as possible up to the check maximum. If the sender doesn't have the funds to at least meet the specified minimum, the transaction fails. +4. If the check expires before the receiver cashes the check, anyone can cancel it. #### Expiration Case @@ -75,13 +70,6 @@ All Checks start the same way, so **Steps 1 and 2** are the same. - -## Availability of Checks - -The Checks amendment became enabled on the XRP Ledger Mainnet on 2020-06-18. For more information about how amendments are enabled and voted on, see [Amendment Process](../../../../amendments/amendments.md#amendment-process). - -To check the status of an amendment on a test network or private network, use the `feature` method. - Moved to checks.md From 60b690c6b0fabed9e66e7d5212f9597a0a9205fa Mon Sep 17 00:00:00 2001 From: Oliver Eggert Date: Mon, 12 Dec 2022 21:11:15 -0800 Subject: [PATCH 5/8] Add note to account_objects.md about commandline interface type field. --- .../public-api-methods/account-methods/account_objects.md | 2 ++ .../use-checks/look-up-checks-by-recipient.md | 1 + .../use-checks/look-up-checks-by-sender.md | 1 + 3 files changed, 4 insertions(+) diff --git a/content/references/http-websocket-apis/public-api-methods/account-methods/account_objects.md b/content/references/http-websocket-apis/public-api-methods/account-methods/account_objects.md index 15a330324b..5cf0343eb6 100644 --- a/content/references/http-websocket-apis/public-api-methods/account-methods/account_objects.md +++ b/content/references/http-websocket-apis/public-api-methods/account-methods/account_objects.md @@ -81,6 +81,8 @@ The request includes the following parameters: | `limit` | Number | _(Optional)_ The maximum number of objects to include in the results. Must be within the inclusive range `10` to `400` on non-admin connections. The default is `200`. | | `marker` | [Marker][] | _(Optional)_ Value from a previous paginated response. Resume retrieving data where that response left off. | +**Note:** The commandline interface to the `account_objects` command doesn't accept the `type` field. Use the [json method][] to send the JSON-RPC format request on the commandline instead. + ## Response Format An example of a successful response: diff --git a/content/tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-recipient.md b/content/tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-recipient.md index 46bddcc21d..882af8839b 100644 --- a/content/tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-recipient.md +++ b/content/tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-recipient.md @@ -15,6 +15,7 @@ This tutorial shows how to look up [Checks](checks.html) by their recipient. You To get a list of all incoming and outgoing Checks for an account, use the `account_objects` command with the recipient account's address and set the `type` field of the request to `checks`. + **Note:** The commandline interface to the `account_objects` command does not accept the `type` field. You can use the [json method][] to send the JSON-RPC format request on the commandline instead. ### Example Request diff --git a/content/tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-sender.md b/content/tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-sender.md index b273c0d6f6..619a7236c5 100644 --- a/content/tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-sender.md +++ b/content/tutorials/use-specialized-payment-types/use-checks/look-up-checks-by-sender.md @@ -17,6 +17,7 @@ This tutorial shows how to look up [Checks](checks.html) by their sender. You ma To get a list of all incoming and outgoing Checks for an account, use the `account_objects` command with the sending account's address and set the `type` field of the request to `checks`. + **Note:** The commandline interface to the `account_objects` command does not accept the `type` field. You can use the [json method][] to send the JSON-RPC format request on the commandline instead. ### Example Request From 36ec9a09b905a0ceef93d4998c6bf5ad5d69fdb3 Mon Sep 17 00:00:00 2001 From: Oliver Eggert Date: Mon, 12 Dec 2022 21:25:13 -0800 Subject: [PATCH 6/8] Merge expiration case with lifecycle section. --- .../concepts/transactions/payments/checks.md | 40 ++++--------------- 1 file changed, 7 insertions(+), 33 deletions(-) diff --git a/content/concepts/transactions/payments/checks.md b/content/concepts/transactions/payments/checks.md index 4af1065dd6..a1733e66b1 100644 --- a/content/concepts/transactions/payments/checks.md +++ b/content/concepts/transactions/payments/checks.md @@ -7,9 +7,9 @@ labels: --- # Checks -The Checks feature enables users to create deferred payments, similar to personal paper checks. Unlike an escrow or payment channel, funds aren't set aside when a check is created, so money only moves when the check is cashed. If the sender doesn't have the funds at the time a check is cashed, the transaction fails; recipients can retry failed transactions until the check expires. +The Checks feature enables users to create deferred payments similar to personal paper checks. Unlike an escrow or payment channel, funds aren't set aside when a check is created, so money only moves when the check is cashed. If the sender doesn't have the funds at the time a check is cashed, the transaction fails; recipients can retry failed transactions until the check expires. -XRP Ledger Checks may have expiration times after which they may no longer be cashed. If the recipient doesn't successfully cash the Check before it expires, the Check can no longer be cashed, but the object remains in the XRP Ledger until someone cancels it. Anyone may cancel the Check after it expires. Only the sender and recipient can cancel the Check before it expires. The Check object is removed from the Ledger when the sender successfully cashes the check or someone cancels it. +XRP Ledger Checks can have expiration times after which they may no longer be cashed. If the recipient doesn't successfully cash the Check before it expires, the Check can no longer be cashed, but the object remains in the XRP Ledger until someone cancels it. Anyone may cancel the Check after it expires. Only the sender and recipient can cancel the Check before it expires. The Check object is removed from the Ledger when the sender successfully cashes the check or someone cancels it. ***TODO: Don't think this needs to be noted here. Is the behavior change documented on the reference page?*** **Note:** The Checks amendment changes the expiration behavior of the `OfferCreate` transaction. @@ -17,7 +17,7 @@ XRP Ledger Checks may have expiration times after which they may no longer be ca ***TODO: Repurpose this into use cases.*** -## Why Checks? +## Use Cases - Checks allow people to exchange funds using a process that is familiar to and accepted by the banking industry. @@ -27,7 +27,7 @@ XRP Ledger Checks may have expiration times after which they may no longer be ca - Flexible check cashes. Specify a min amount up to maxamount to cash. -### Use Case: Payment Authorization +### Payment Authorization **Problem:** To comply with regulations like BSA, KYC, AML, and CFT, financial institutions must provide documentation about the source of funds they receive. Such regulations seek to prevent the illicit transfer of funds by requiring institutions to know the source and destination of all payments processed by the institution. Because of the nature of the XRP Ledger, anyone could potentially send XRP (and, under the right circumstances, tokens) to an institution's account on the XRP Ledger. Dealing with such unwanted payments adds significant cost and time delays to these institutions' compliance departments, including potential fines or penalties. @@ -48,33 +48,14 @@ XRP Ledger Checks may have expiration times after which they may no longer be ca 3. The recipient submits a `CheckCash` transaction that transfers the funds and destroys the `Check` object. **Note:** Recipients have two options for cashing checks. - Exact Amount: They specify an exact amount to cash that doesn't exceed the check maximum. - - Flexible Amount: They specify a minimum amount to cash and the XRP Ledger delivers as much as possible up to the check maximum. If the sender doesn't have the funds to at least meet the specified minimum, the transaction fails. + - Flexible Amount: They specify a minimum amount to cash and the XRP Ledger delivers as much as possible up to the check maximum. If the sender doesn't have the funds to meet the minimum, the transaction fails. -4. If the check expires before the receiver cashes the check, anyone can cancel it. - - -#### Expiration Case - -In the case of expirations, Checks have the lifecycle described below. - - - -[![Check flow diagram (expiration)](../../../../img/checks-expiration.png)](../../../../img/checks-expiration.png) - - -All Checks start the same way, so **Steps 1 and 2** are the same. - -**Step 3a:** If the Check expires before the recipient can cash it, the Check can no longer be cashed but the object remains in the ledger. - -**Step 4a:** After a Check expires, anyone may cancel it by submitting a [CheckCancel][] transaction. That transaction removes the Check from the ledger. +4. If the check expires before the receiver cashes the check, the `Check` object remainds until anyone cancels it. - \ No newline at end of file + - [Cancel a Check](cancel-a-check.html) \ No newline at end of file From 748dfa1c6e89108f5473896f523e3209b5c339ca Mon Sep 17 00:00:00 2001 From: Oliver Eggert Date: Mon, 12 Dec 2022 22:42:18 -0800 Subject: [PATCH 7/8] First draft of updated checks.md --- .../concepts/transactions/payments/checks.md | 46 ++++++++----------- 1 file changed, 18 insertions(+), 28 deletions(-) diff --git a/content/concepts/transactions/payments/checks.md b/content/concepts/transactions/payments/checks.md index a1733e66b1..5e551b9692 100644 --- a/content/concepts/transactions/payments/checks.md +++ b/content/concepts/transactions/payments/checks.md @@ -7,33 +7,7 @@ labels: --- # Checks -The Checks feature enables users to create deferred payments similar to personal paper checks. Unlike an escrow or payment channel, funds aren't set aside when a check is created, so money only moves when the check is cashed. If the sender doesn't have the funds at the time a check is cashed, the transaction fails; recipients can retry failed transactions until the check expires. - -XRP Ledger Checks can have expiration times after which they may no longer be cashed. If the recipient doesn't successfully cash the Check before it expires, the Check can no longer be cashed, but the object remains in the XRP Ledger until someone cancels it. Anyone may cancel the Check after it expires. Only the sender and recipient can cancel the Check before it expires. The Check object is removed from the Ledger when the sender successfully cashes the check or someone cancels it. - -***TODO: Don't think this needs to be noted here. Is the behavior change documented on the reference page?*** -**Note:** The Checks amendment changes the expiration behavior of the `OfferCreate` transaction. - - - -***TODO: Repurpose this into use cases.*** -## Use Cases - -- Checks allow people to exchange funds using a process that is familiar to and accepted by the banking industry. - -- XRP Ledger Checks solve a problem that is unique to the Ledger: they enable users to reject unwanted payments or accept only part of a payment. This is useful for institutions that need to be careful about accepting payments for compliance reasons. - -- If your intended recipient blocks direct payments from stranger using deposit authorization, a check is a good alternative. - -- Flexible check cashes. Specify a min amount up to maxamount to cash. - -### Payment Authorization - -**Problem:** To comply with regulations like BSA, KYC, AML, and CFT, financial institutions must provide documentation about the source of funds they receive. Such regulations seek to prevent the illicit transfer of funds by requiring institutions to know the source and destination of all payments processed by the institution. Because of the nature of the XRP Ledger, anyone could potentially send XRP (and, under the right circumstances, tokens) to an institution's account on the XRP Ledger. Dealing with such unwanted payments adds significant cost and time delays to these institutions' compliance departments, including potential fines or penalties. - - - -**Solution:** Institutions can enable deposit authorization on their XRP Ledger accounts by setting the `asfDepositAuth` flag in an `AccountSet` transaction. This makes the account unable to receive Payment transactions. Accounts with Deposit Authorization enabled can only receive funds through Escrow, Payment Channels, or Checks. Checks are the most straightforward, familiar, and flexible way to transfer funds if Deposit Authorization is enabled. +XRPL Ledger checks enable users to create deferred payments similar to personal paper checks. Unlike an escrow or payment channel, funds aren't set aside when a check is created, so money only moves when the check is cashed. If the sender doesn't have the funds at the time a check is cashed, the transaction fails; recipients can retry failed transactions until the check expires. ## Check Lifecycle @@ -50,7 +24,23 @@ XRP Ledger Checks can have expiration times after which they may no longer be ca - Exact Amount: They specify an exact amount to cash that doesn't exceed the check maximum. - Flexible Amount: They specify a minimum amount to cash and the XRP Ledger delivers as much as possible up to the check maximum. If the sender doesn't have the funds to meet the minimum, the transaction fails. -4. If the check expires before the receiver cashes the check, the `Check` object remainds until anyone cancels it. +4. If the check expires before the receiver cashes the check, the `Check` object remains until someone cancels it. + + +## Use Cases + +### Deposit Authorization + +**Problem:** To comply with regulations like BSA, KYC, AML, and CFT, financial institutions must provide documentation about the sources of funds they receive. These regulations seek to prevent illicit activity by requiring institutions to track the source and destination of all payments they process. Because of the nature of the XRP Ledger, anyone can send XRP to an institution's account on the ledger; to prevent this behavior, they'll enable deposit authorization to only receive funds they explicitly approve. + + + +**Solution:** Accounts with deposit authorization enabled can only receive funds through: + - Preauthorized Accounts + - Escrow + - Payment Channels + - Checks +Checks are the most straightforward, familiar, and flexible way to transfer funds when deposite authorization is enabled. From df8294862a42aecf54e1b768bc83169fa0d04371 Mon Sep 17 00:00:00 2001 From: Oliver Eggert Date: Tue, 13 Dec 2022 16:31:38 -0800 Subject: [PATCH 8/8] Remove specificy of banking regulations, per suggestion. --- content/concepts/transactions/payments/checks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/concepts/transactions/payments/checks.md b/content/concepts/transactions/payments/checks.md index 5e551b9692..5f2c54b678 100644 --- a/content/concepts/transactions/payments/checks.md +++ b/content/concepts/transactions/payments/checks.md @@ -31,7 +31,7 @@ XRPL Ledger checks enable users to create deferred payments similar to personal ### Deposit Authorization -**Problem:** To comply with regulations like BSA, KYC, AML, and CFT, financial institutions must provide documentation about the sources of funds they receive. These regulations seek to prevent illicit activity by requiring institutions to track the source and destination of all payments they process. Because of the nature of the XRP Ledger, anyone can send XRP to an institution's account on the ledger; to prevent this behavior, they'll enable deposit authorization to only receive funds they explicitly approve. +**Problem:** To comply with banking regulations, financial institutions must provide documentation about the sources of funds they receive. These regulations seek to prevent illicit activity by requiring institutions to track the source and destination of all payments they process. Because of the nature of the XRP Ledger, anyone can send XRP to an institution's account on the ledger; to prevent this behavior, they'll enable deposit authorization to only receive funds they explicitly approve.