updated Outline of handling incoming transactions

bsip-0040.md

@@ -150,13 +150,15 @@ Stateless assert, only for dictionary type objects. The data is a list of restri
 ### Outline of handling incoming transactions
  
 When a signed transaction arrives and before the backend evaluates if all necessary authorities are present through the signatures, do the following:
-- iterate over required accounts and for each account, iterate over all operations (child operations of proposal are not iterated, only the proposal) within the transactions that require the active authority of this account
-- iterate the `custom_active_authorities` of said account
-- if a `custom_active_authority` is found that matches , remember that and stop iterating the authorities and continue until all operations are checked
-- if the account has a `custom active authority` match for every operation in the transaction that requires it, then grant the `active authority` of said account. If no match is found, treat as if no authority was given
+- iterate over `required accounts`
+  - iterate over all `operations` (child operations of proposal are not iterated, only the proposal) within the transactions that require the active authority of this account
+    - iterate the `custom_active_authorities` of this account, and if it matches, remember that and continue with next `operation`
+  - if a `custom active authority` match was found for every operation in the loop, grant the `active authority` of this account
 
 Note:
 - A `custom_active_authority` can only grant the `active authority` of the corresponding account, nothing more
+- The actual active authority of a required account can still be given as before, existing behavior is not to be changed
+- This for illustration, not actual implementation instructions
 
 ### Economics