By now, there already is a swagger spec in the development branch.

I took a peek at it.

Some random thoughts (with adding some annotations about visibility/permissions) for regular users:

DELETE /users should be moved to DELETE /users/{userId}, while only allowing each user to delete its own account.
PUT /users -> PUT /users/{userId} (same reasons as 1.)
regarding /messages: Maybe types of sender, recipient and content would need to be redefined (pointing to user ids, so you can look those up via GET /users/{userId}, or embed via embed parameter, renaming content to data and setting type to json to support multiple fields?)
regarding #/components/schemas/Group: Why is owner not owners, and a list (with possibly more than one owner)?
I'd suggest stripping GET /groups/{groupId}/users, and instead let GET /groups/{groupId} return a members attribute with a list of user ids (also possible to embed)
The group joining and authorization flow is unclear to me, and violates Keep URLS Verb-Free, Avoid Actions — Think About Resources. Can users request access, or are they only invited to a group (which they can accept)? I'd suggest a /user/{userId}/invitations endpoint, with group owners being able to POST to random users /user/{userId}/invitations endpoint, and users being able to PATCH/PUT /groups/{groupId}/users, as soon as there exists an invitation (which will then be deleted as well)
The /groups/{groupId}/transactions/{transactionId} could be moved to /transactions/{transactionId}. (see Consider Using (Non-) Nested URLs)

API Documentation #3

Description