The Scrum Guide states that a Scrum team should have all the skill necessary to deliver a product increment.
The idea is that a team will take one or more features and fully implement them by the end of a sprint. Scrum teams own the features they are working on and this will include system testing and deployment.
When you have multiple Scrum teams working on the same product then a common practice is to have each team working on a feature theme (for example, one team could be working on security features and another might be working on personalisation features).
Regardless of how the work is divided between the teams the approach is the same. Each team takes full responsibility for the delivery of a feature until it is potentially releasable.
In you situation I would suggest you consider:
- Having the system testers join your Scrum teams
- Having Scrum teams own features end-to-end
- Divide work between your teams based on a criteria such as feature themes (empower the teams to work out the best approach to dividing the work)
You may also want to reconsider the way you do your automated testing. A lot of automated testers I have worked with will start on the tests at the same time as development starts. They do not wait for development to finish before they start to create the automated tests.
A common approach is for the developers to quickly produce a stub release that mimics the feature they are about to develop. The testers then immediately get started on writing a test. Once the developers have finished development they swap out the stub and replace it with the real code.