diff --git a/bsip-0040.md b/bsip-0040.md
index 13d43be..73f6f69 100644
--- a/bsip-0040.md
+++ b/bsip-0040.md
@@ -115,7 +115,7 @@ Statefull assert, only `int` type arguments. Analogue to `limit`, but `interval_
 #### `contains_only`
 Stateless assert, only for dictionary type objects like `options`. The `argument` of the operation is a dictionary type objects and is only allowed to contain the attributes in the data list.
 
-### Example: Simple transfer
+#### Example: Simple transfer
 Assume account A and B and some unrelated key K. Furthermore A has a custom active authority in the following way:
 ```
 custom active authority = {
@@ -151,14 +151,20 @@ When a signed transaction arrives and before the backend evaluates if all necess
 Note:
 - A `custom_active_authority` can only grant the `active authority` of the corresponding account, nothing more
 
-### Example: Checking for custom active authorities
+#### Example: Checking for custom active authorities
 
 Assume Account A, B and C. Now A has two `custom active authorities`:
 
  - `custom active authority 1`: Allow Account B to transfer asset X to D
  - `custom active authority 2`: Allow Account C to transfer asset X to D
 
-The incoming transaction now contains `transfer 100 asset X from A to D, signed by all signatures required for active authority of C`. The required accounts (meaning required active authority) for the transaction is Account A. Backend would start considering `custom active authority 1` and check if active authority of account B is present through signatures. It is not, thus continue by checking if authority of `custom active authority 2` is present, which it is. Acive authority of Account A is granted and normal authority checks are continued. Since the required accounts is Account A, and the given accounts is also Account A through `custom active authority 2`, the transaction is executed.
+The incoming transaction now contains `transfer 100 asset X from A to D, signed by all signatures required for active authority of C`. 
+The required accounts (meaning required active authority) for the transaction is Account A. 
+Backend would start considering `custom active authority 1` and check if active authority of account B is present through signatures. 
+It is not, thus continue by checking if authority of `custom active authority 2` is present, which it is. 
+Acive authority of Account A is granted and normal authority checks are continued. 
+Since the required accounts is Account A, and the given accounts is also Account A through `custom active authority 2`, 
+the transaction is executed.
 
 ### Modification to the backend
 * Extend the account object to store custom active permission that includes a list of custom active authorities. Multiple custom active authority entries are possible for one operation