You asked many questions:
Is there a way to collect the desired information without risking the person's personal information?
Yes, but it's a different technical model than you're describing. Many card issuers participate in programs with 3rd party vendors designed to facilitate those third parties storing transactional data in order to help their customers do budgeting and track spending. Some card issuers use similar interfaces to participate in third party rewards programs or rewards networks.
Generally, these partnerships rely on an API between the vendor and card issuer, where the issuer is delivering transaction data in a manner that does not expose anything that could directly be used for unauthorized purchases (i.e. the card number). Of course, there needs to be some key between the systems, but it's generally a key implemented solely for this sort of interface, which can't directly be used for fraudulent purposes (i.e. an account number, member number, customer number, etc).
This model does still "risk personal information" in the sense that details considered personal are changing hands, but it has the advantage of not directly risking fraudulent transactions against someone's credit card. This reduces the risk level for the third party.
Can someone spend the user's money with this information? (If so, how?)
Probably, yes. But it will require a bit of sophistication. The CVV is supposed to stop this sort of fraud, but there are loopholes where it's possible to defeat that (making certain payment types via certain processors, a distributed attack to guess the CVV, or using a stolen/hacked terminal).
Does my service have to be pci-compliant? I am processing information that contains the user's credit card number but (1) The client willingly handed it to me (2) I am not extracting this number (3) I am not a credit card company, a merchant, nor their supplier (4) I did not sign a PCI contract, nor do I believe I will have to do so.
As far as I can tell, users are not liable for unauthorized spending on the their credit card and banking accounts so long as they do not give out their password (which they are not). In the case of unauthorized spending, is the user or my service liable for any lost funds?
I'm not sure what password you're referring to, but I don't think it's appropriate to make broad statements about who would be liable, without knowing the protections and compliance efforts you've put into place and the details of a specific attack or breach. Imagine if your users handed over their statements, and you just stored all those pdfs in plain text on a wide open server - then, imagine someone stole them all. Clearly, you would be liable. Of course, hopefully no one providing the types of services you're talking about would be that careless. But, as an extreme example, it should illustrate that we can't make broad statements about whether or not you or the customer would or would not be liable for any fraud.
You should ask your lawyer to clarify responsibility in the case of a breach for you. Keep in mind though, if there is ever a breach on your system, being PCI-DSS compliant can significantly change the outcome of the legal battle that will ensue - following the same set of standards as everyone else in your industry is a good starting point to protecting yourself from liability.
It's also important to note that unauthorized transactions are just one of many risks of storing information related to credit cards or personal finance. Generally, if an attacker gains enough information about an individual's personal details and financial data, they don't need the actual credit card number, because they can execute other attacks - call the bank, pretend to be the customer, and ask for a new card to be issued, then swipe it from the mailbox. Or change some detail on the account. Having someone's entire credit card statement history is a good start towards supporting one of these indirect attacks.
