Based on what I've read, user stories are often cast in a "who", "what", and "why" format, i.e. "[Who] wants the system to do [What], so that [Why]". The "who" and "what" seem easy to grasp. For the example of an ATM:
As a customer
I want to be able to deposit money
The "why" line seems like it could have a significant impact on the scope of the software. For example, all of the following seem like reasonable justifications for the feature; however, the first implies security, insurance, data redundancy, etc...; the second and third imply the existence entirely separate systems; and all three imply data persistence.
So that it will be protected by the bank
So that I can manage my finances online
So that make payments with my debit card
To put it briefly, within the context of agile software development, how are complex/coupled functional requirements handled so that they can be sanely developed?
For example, would the development team derive sets of use cases from such high-level user stories? Or would they re-write the user stories so that they had a limited scope?