that’s a funny situation u just outlined! 
indeed the solution is to create another attribute, since a transaction entity is NOT a user itself, so it shouldn’t have :user/* attributes. It just references a user.
I just recently pondered what should be our naming convention for attributes, which are used to describe Datomic transaction entities and I came up with :datomic.tx/*, which is not prohibited, reasonably concise and has 2-segment namespace, which makes it very unlikely to collide with other names.
Following that idea, your attribute could be called something like
:datomic.tx/by:datomic.tx/origin:datomic.tx/source
Either way, you can also use such an attribute to point to some entity, which represents some system, not necessarily just a human user.
Btw, I strongly discourage everyone to just talk about users (or accounts), without any further qualifications. Most system sooner or later will need to deal with more types of user or accounts and the ambiguity quickly becomes a serious communication hinderance.
For example, I work for https://gini.co, so we have :gini/users, to whom we assign some :gini.user/id UUID attribute, which we generate, but in your case it could be the Cognito user ID (u might even have such an attribute, :cognito.user/id or even :aws.cognito.user/id).
Then these gini users sign up to our system with either their Google user accounts or Xero user accounts (notice how the word account entered the picture!). Those systems have their own user IDs, which we store as :google.user/id & :xero.user/id.
Then these gini users pay us using Stripe, so they will have a :stripe.customer/id.
However, we are planning to allow our users - the gini users - to share their own Stripe data with our system. For that, they will have to use OAuth authorization, after signing in with their Stripe user credentials to Stripe. Such an authorization is then implicitly tied to their Stripe user account, which they used as an :oauth.client/user (or just :oauth/user), which would point to a Stripe user entity, which would have a :stripe.user/id.
Xero is an accounting system, so naturally it manages “accounts”, but in the financial sense!
So while they have user accounts, they have financial accounts too!
We ended up calling those accounting accounts, for the sake of disambiguation, because we also use HubSpot, which has a bunch of other (user) account types:
Marketing departments also calls have a special meaning for accounts; they mean a logical entity, which is comprised of 1 or more legal entities and 1 or more contact persons, called contacts for short. If I would need to model them in Datomic, I’d use :hubspot.marketing.account/id, :hubspot.user/id, :hubspot.contact/id.
If an employee of a company becomes a user of the company’s product, then i would even mix their :gini.user/id & :hubspot.contact/id on the same entity (if they would be in the same Datomic database).
so it seems this is where it gets confused trying the